[Matroska-devel] Re: [mpc-devel] Re: Protocol of my 2+ hrs telephone conversation with Frank Klemm

Christian HJ Wiesner chris at wiesneronline.net
Mon Nov 17 23:26:17 CET 2003

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). 
Welcome to the list Michel. Its good to see other developers are reading 
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 
here about .... much much better than my background ;) .

>I have to say I was quite surprised to see mpc, using subband
>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.
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.
Now i remember Frank told me about this one also during the 2 hours :O 
.... 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)
Why would you chose AC3 over AAC ? Frank told me about some 'quirks' the 
AAC format has, like a missing latency time description and the like, 
but are you aware of any more limitations, or advantages of AC3 compared 
to AAC ?

>>It appears to me that Frank alone can not invest the time necessary to 
>>realize MPC SV8. On the other hand he could very well make the specs, 
>>and invest time into his main area of excellence, the psy model. He 
>>mentioned to me that he had invested too much time already into 
>>explaining what has to be done to other people, but without any real 
>>feedback from them after that.
>Huh, I *really* know that feeling.
;) ...... if you ever feel like working in a team, and wnat to try 
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.
>OK so this is maybe a naive question from an outsider, but I'll ask it
>What's wrong with mpc for use with video ?
The current bitstream ( SV7 ) makes it impossible to clearly find out 
where a block/frame starts and ends. Sometimes bit from one block are 
stored with bits from another block, etc. This may not be a problem for 
'simpler' video containers, but the matroska container requests some 
very clear rules here to be respected, like the 'one block/frame in one 
matroska block' rule. Also, the MPC decoder may require up to 32 blocks 
before the actual block to be able to decode it, making seeking in the 
file generally a problem, not only for video, but for video seeking is 
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.
This will not be an issue anymore once the encoder goes final, as Frank 
promised to make it OSS then. The host and CVS for this is already up, 



More information about the Matroska-devel mailing list