Re: Protocol of my 2+ hrs telephone conversation with Frank Klemm

Michel Lespinasse wrote:

>As it's my first post here, I thought I should introduce myself. I'm
>the main developper on a few projects, most notably liba52 (AC-3
>decoding library) and libmpeg2 (mpeg2 decoding).=20
>
Welcome to the list Michel. Its good to see other developers are reading=20
this list.

>I've not used mpc
>much to date, but I did look at the SV8 stream format description and
>found it quite clean. I also implemented some mpeg audio layer 1-2
>decoder in the past, but I never touched layer 3 (because I think the
>spec is so ugly). Just letting people know so they see where I'm
>coming from.
>
It appears to me you have a very good background in what we are talking=20
here about .... much much better than my background ;) .

>I have to say I was quite surprised to see mpc, using subband
> =20
>
>transforms so similar to mpeg audio layer 2, can perform so well. MPC
>stream format has a lot of improvements over mpeg audio layer 2
>though, with a bunch of different huffman tables you can select from,
>some including various amouts of shaping as well. So I was wondering
>how much of the improvement is due to the stream format enhancements,
>and how much is due to the psy model.
> =20
>
Frank says that the psy model seems to be the key here.

>I think the AC3 format has a lot of potential too, but currently the
>free encoders for it kinda suck. One of the interesting features of
>AC3 is that the decoder performs a bit allocation using a default
>standardized psy model - if the encoder has a better psy model, it can
>transmit deltas to apply to that bit allocation, but the idea is that
>in the end it should be cheaper to transmit these deltas than to
>transmit a whole bit allocation information. However, all free
>encoders are crappy in the respect that they dont even have their own
>psy model - they just use whatever is the result of the default psy
>model in the AC3 decoder.
> =20
>
Now i remember Frank told me about this one also during the 2 hours :O=20
.... but i forgot to mention it in the report.

>Anyway. I believe a mdct based format such as AC3 would have a lot of
>potential if combined with a smart encoder using a good psy
>model. Regarding what frank told you, I'd be curious if he was
>considering a straight AC3 format encoder, or doing an AC3-derived
>format with stream format improvements similar to what he's done in
>mpc (i.e. the various shaped tables etc)
> =20
>
Why would you chose AC3 over AAC ? Frank told me about some 'quirks' the=20
AAC format has, like a missing latency time description and the like,=20
but are you aware of any more limitations, or advantages of AC3 compared=20
to AAC ?

>>It appears to me that Frank alone can not invest the time necessary to=20
>>realize MPC SV8. On the other hand he could very well make the specs,=20
>>and invest time into his main area of excellence, the psy model. He=20
>>mentioned to me that he had invested too much time already into=20
>>explaining what has to be done to other people, but without any real=20
>>feedback from them after that.
>>   =20
>>
>
>Huh, I *really* know that feeling.
> =20
>
;) ...... if you ever feel like working in a team, and wnat to try=20
something new, give us a shout :) !

>>Its time for us to ask ourselves if we want musepack to evolve
>>further, or if we are happy with what it is today. Whilst it is
>>usable for music compression already, its not for use with video. If
>>we want musepack to progress, we all have to work together to
>>improve it. Looking forward to hear your comments.
>>   =20
>>
>
>OK so this is maybe a naive question from an outsider, but I'll ask it
>anyway.
>
>What's wrong with mpc for use with video ?
>
The current bitstream ( SV7 ) makes it impossible to clearly find out=20
where a block/frame starts and ends. Sometimes bit from one block are=20
stored with bits from another block, etc. This may not be a problem for=20
'simpler' video containers, but the matroska container requests some=20
very clear rules here to be respected, like the 'one block/frame in one=20
matroska block' rule. Also, the MPC decoder may require up to 32 blocks=20
before the actual block to be able to decode it, making seeking in the=20
file generally a problem, not only for video, but for video seeking is=20
maybe much more vital than for audio sometimes.

>>From my point of view, the main thing holding mpc back nowadays is the
>lack of a free encoder source code.
>Cheers,
> =20
>
This will not be an issue anymore once the encoder goes final, as Frank=20
promised to make it OSS then. The host and CVS for this is already up,=20
http://corecodec.org/projects/mpc

Regards

Christian




http://mpc.corecodec.org