Re: Protocol of my 2+ hrs telephone conversation with Frank Klemm
Michel Lespinasse <[email protected]> Sun, 16 Nov 2003 22:42:10 -0800
| Newsgroups | gmane.comp.audio.mpc.devel,gmane.comp.multimedia.matroska.devel,gmane.comp.audio.mpc.general |
|---|---|
| Message-ID | <[email protected]> |
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). 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. On Sun, Nov 16, 2003 at 11:19:18AM +0100, Christian HJ Wiesner wrote: > 1. Subband coding vs. Transformation coding > 2. Future of MPC > 3. MPC in matroska > 4. DVD players and their problems > > 1. I was very surprised to understand that Frank doesnt see any > benefit in musepack's subband coding, compared to modern > transformation codecs like AAC or even Vorbis. He told me that > musepack's results in the 128 kbps listening test are a slap in the > face of the other codecs, as normally musepack should have performed > worst at this bitrate. He is of the opinion that musepack's only > advantage is the psy model he made, or the lack of there-of in the > other codecs. > > Not even in the decoding speed does he see a big advantage in subband=20 > coding, he is convinced all of the other decoders could be optimized a=20 > lot, especially with improvements in the lookup of the huffman tables,=20 > with a proper indexing system as he has done with musepack once, gainin= g=20 > a speed advantage of factor 9 compared to buschel's code. > He mentioned more than one time that MP3, from his point of view, is no= t=20 > at all well specified and implemented and can even lead to drop-outs=20 > during playback under certain conditions. He sees AC3 as a very good=20 > standard for his needs, because of well existing hardware decoders in=20 > external receivers, a proper and well done specification and=20 > implementation, and because with DVD burners beoming more and more=20 > popular, low bitrates for audio compression will be only interesting fo= r=20 > streaming in future, and he doesnt see the big market for streaming at=20 > all. He told me he is maybe interested in making a proper AC3 encoder,=20 > using his own psy model, that in principal can be transferred from one=20 > encoder to another. 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. 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. 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) > 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. Huh, I *really* know that feeling. > 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 anyway. What's wrong with mpc for use with video ? From my point of view, the main thing holding mpc back nowadays is the lack of a free encoder source code. Cheers, --=20 Michel "Walken" Lespinasse "In this time of war against Osama bin Laden and the oppressive Taliban regime, we are thankful that OUR leader isn't the spoiled son of a powerful politician from a wealthy oil family who is supported by religious fundamentalists, operates through clandestine organizations, has no respect for the democratic electoral process, bombs innocents, and uses war to deny people their civil liberties." --The Boondocks http://mpc.corecodec.org