Christian mpc.corecodec.org doesn't work...

well, Frank K. is The man.


my thoughts:

these days space isn't such an issue any more, even not for video.
You can compress mpeg2 video a little bit more, and fit a lot on DVD+-R/Video.

As audio stream you can use the original ac3, if your purpose is an backup.

But:
ac3 isn't that perfect, dts would be.

So, what we need since some loner time:

multichannel "mpc", as SV7, 7.5 or 8,
the end-user won't care as long as it runs smooth.

For self-made video maaybe HQ stereo is needed, too,
so matroska with mpc is needed !

Of course, the end-users won't care much about the name, mpc, ac3, or aac.

So, in fact, it would be fine, if Frank K. (together with others) could either make an improved AAC (or ac3 if possible, but imo, ac3 has a very weak sound, so I dunno, if good sound is possible at all with ac3).

A final mpc SV7, 7.5 or SV8 would be nice, too.
I think, the psy-model does not need more tweaking at this time.
You would have to invest really a lot time for tweaking and testing, abxing,
but results, improvements would be minor at this stage, MPC has already reached (see the 128k test at the bottom line...)

So, the work should concentrate on that, what Citay told, including --xlevel eg.
And the possibility to include this stereo mpc into video container.
Maybe this 2 topics should be differentiated.
As it seems, that including SV7 into video properly is a little bit difficult, it might be the good idea to make SV7 final, like others proposed here.
And simply make a proper SV8 stream definition, for video, maybe multichannle, too ?, using the excellent psy-model of current SV7.

well, imo, a bitratesaving multichannel codec needs a lot tweaking to the perfection, mpc stereo has currently.
But imo, the optimizing for multichannle can be done later, if the "container" SV8 would work in general.



well, as Christian told, Frank K. has already sent a detailed ToDo List, nobody knows better, what to do, than him !

DTS is closed, proprietary and CBR. It also barely uses psychoacoustics, the processing is almost only quantization. It's only supported on DVD players and receivers, and you won't find specifications nor reference sources anywhere. It's as bad a choice as it can be.

Sorry, I meant an AAC encoder focussed on transparency would be nice. The ones out there right now, while having extremely capable developers working on them, tend to be focussing on the lower bitrates. I would assume any work Frank would be involved with would lean more towards what we around here are interested in.

IMHO if Frank (or any other dev) could fix the problems MPC has with some problematic samples on -q 5+ it would be more than enough for now and maybe in the future (near?) him and other devs could work on low bitrate tweaking, multichannel, implementing SV8, the AAC decoder idea, etc.

Well, no matter, wht project Frank would be in, but let's all wish him luck.
We have at least MPC. With all its limitations, advantages and so on...
If Frank would decide to make an AC3 codec or another free AAC encoder, I'm sure, he'll make a good job.
Guys, let's stop moaning about "MPC's death". Those of you, who don't like it still have a whole damned lot of other formats.
Whatever Frank decides, it's his decision and we MUST respect it.

Were working on CoreCodec.org ATM it will be back up soon. If not already ;-)

So far MusePack is the closest a lossy codec has come to being "transparent" IMHO... so although it looks like its "dead" this is format for "transparent" lossy encoding. (Although at the rate AAC is going we might have to look at that soon ).

Regards

AgentMil

well, DTS is the best you get in theaterland. AC3 is an earsore. however, i didn't see the point in bringing it home once it GOT home, seeing as how AC3 had a sufficiently high enough bitrate not to sound fugly on DVD. but this is extremely OT.

I am sorry if anyone has misinterperrated what I have said or been offended. There are clearly very talented ppl currently working on AAC, but their focus seems to be on low bit rate encoding, something I could care less about. Frank is concerned almost solely with transparency - the thing IM most concerned about. So if Frank can bring his knowledge, expertiece, and approach to AAC that would be amazing. He also hinted that he could greatly reduce the CPU load for decoding AAC files similiar to MPC. The origninal post sounded like Frank thought he could do everything he has done for MPC with AAC, so basically you would get MPC with wide industry support! Thats PERFECT for my needs.

I'm not an codec expert,

but i like the idea to develop a psy model witch can be used by nearly every codec. I would also like to have a free ac3 and or dts encoder. A free aac encoder which can be used on every platform would be great too.

But if i think twice, i would say "let's make a new mp3 encoder!". With Frank's psy model acknowledgement it should be possible to build a new mp3 encoder which works only in vbr and can reach true transparency, including overtones and a even frequency response from 20 Hz to 20 kHz.

Call me ignorant, but for me as musican the existing codecs dosn't satisfy my needs. I use FLAC to archive my own recordings and MP3 or Vorbis to distribute preview songs. But for listening music on a walkman or in living room i switched back to good old audio cds. One codec sounds good but playback is only possible on a computer. The other codec is present at nearly every device like dvd players, computers, cellphones, walkmans etc. but can never reach transparency and sounds only good if you compile them with the intel compiler from 1998 on a WindowsNT 4.0 with xyz compiler flags in a full moon night.

There are so many people with codec skills which have spend hundreds of hours to different audio formats. Would it be possible to merge the whole horsepower into one project, people would have the best audio codec, available for every platform and every device.

Just my four cents
BadHorsie

Well, as you can see here, Frank Klemm was once a developer in the LAME team. He wanted to do some pretty radical code overhaul, which lead to discrepancies within the dev group (mainly Mark and Naoki) and eventually to him quitting and later starting to work on MPC.

I think MP3 is too limited (sfb21, fixed bitrates, no multichannel, no 24bits depth, no frequencies higher than 48kHz, bitrates limited to 320kbps...) to use Frank's psychoacoustic model's full power.

Adapting one of the several analogies that were in vogue here at HA some time ago, it's like putting a Boeing engine in a VW Beetle :B

I agree, except on this part:

I was posting some answers back to Frank about his last proposal to make a SV7 to SV8 conversion tool, the email is mirrored here

For your convenience i copy and paste the content here also :

Christian HJ Wiesner wrote:



Forgive me if i am talking complete rubbish, but i have more and more
problems understanding what you are trying to do here :

From my understanding the SV8 framing should not only bring a new
framing, but also introduce serious changes to the blocks itself ? If
you make an app that simply 're-packs' SV7 files into a SV8 framing,
will the old blocks be converted also, so they are SV8 compliant, or do
you plan to introduce a 'SV7 compatibility mode' in SV8, so that SV7
blocks can be put into the new framing ?

For the changes to the blocks itself, i do understand that the follwoing
new features require a new block design :

- multichannel ( 5.1 )
- more flexible sampling rate support
- DRC
etc.

Now with respect to what you told me on the phone, i mean your ideas
about leaving the subband encoder design completely for next musepack,
how about considering tow steps for this :

1. SV8 : subband encoder like SV7, but adding all the new features
listed above

2. SV9 / new codec name : new encoder based on tranformation encoding,
or a new OSS AAC encoder

Christian

Exactly what bitrate increase are we on about Christian? Anything major essentially reduced the efficiency of musepack compared to other codecs. I understand why it needs to be done because of the matroska container format, but isn't there another way? As far as I can see you're taking the top and bottom of each frame and adding it to the surrounding frames, that's surely a bit wasteful?

Whatever - i'll still look forward to it. Nice to see you still have a dialogue with Frank.

sean

Ok,

MP3 is a very old format and restricted in many ways. But it is the only format with true hardware support, isn't it? It is the only format witch works on every platform too.

As for AAC, i would understand the hype if i where on a Windows or Apple box. But as a Linux only user AAC is nothing than a buzzword for me.

It seems that i have to pay EUR 3000,- for a Apple Powerbook and EUR 600,- for a IPod if i want to listen music in the future, or just stay with AudioCD/Cassette combination.

I believe that SV8/9 could get a really nice audio codec but we have to wait a long time to play those files on any hardware outside a computer, if ever.

It seems to me that every development since CD_DA was a step backward, really.

BadHorsie

BTW: There are many Live DVDs wich come mastered with a 5.1 AC3 track @ 384 kbs which sounds not bad. So the 320 kbs limitation in MP3 should not be a really problem for two channel tracks if the encoder would be carefully tuned. And 16 kHz limitaion should not be a big problem too. Most midrange CD Players have a frequency response limited from 30 Hz to 16 kHz and can sound really good if bundled with good cable/speaker combination. But as i said before, i'm not an codec expert.

Are you saying that current recommended LAME encoder doesn't sound transparent on most things at 320 Kbps? I bet it's more thansparent than 5.1 channel 384 Kbps AC3. If you mean that, then I'd say you are being victim of placebo effect. Try some ABX tests with the recommended --aps, --ape and --api LAME presets, and check for yourself how severe are transparency problems.



If I'm not wrong, it's a limitation on encoding efficiency, nothing else. LAME alt-presets lowpass quite over this 16 KHz frequency. Very little real-world music is affected audibly from these lowpasses.



In this context, the cable would be the least important of your concerns.

Edit: sorry if I'm taking some things out of context.

I would be interested in seing Musepack's benefits into AAC or AC3.

Christian, do you think it is possible to obtain the SV7 encoder sourcecode? I've sent a couple of emails to Frank but got no reply (I think I don't have his most recent email addy) ... if he would insist on keeping the source closed/non public (for any reason) I would of course respect that and keep all the work private.

Thanks

A sinful compression for walkman usage would be 160 kbs - 224 kbs average. A complete album in 320 kbs makes no sense. I just want to say that 320 kbs frames should be enough in a VBR situation to handle critical samples.

I did a lot of ABX tests with the --alt-presets (especially --alt-preset standard vs. --alt-preset fast standard with LAME 3.90.3 and 3.92).



This is what i want to say. Even if the --alt-presets would lowpass at 16 kHz it would enough in most situations.

BadHorsie

"ac3 isn't that perfect, dts would be."

I meant this simply by comparing the resulting listening quality.
ac3 5.1 capped at 448 kbit/s, sometimes only 5.1 in 384 kbit/s.

Of course, dts uses way higher bitrates.

Actually Dibrom got it with the help of Case.... So maybe you should talk to them.

Just for clarification, especially on Case's part, Case did provide the sources to me but only because Frank had given him explicit permission to do so beforehand.

I think it's necessary to at least try and get a response from Frank first before the sources are distributed to someone.

Sure. I'll try to PM Case and ask if he could get me the permission (or at least Frank's email).

Thanks

I agree 100%.

On a Linux box, you have the choice between LAME, Ogg Vorbis and FAAC - they seem to be the only decent open source encoders. MPC binaries are available too. I don't quite understand what all the fuss is about? You have access to three decent encoders, and if you own an x86 box, you can even run the remaining through WINE.

You know, reading it, I got the impression that Mr. Frank Klemm was a sort of guru who's insights were coveted by many but understood by few

Interesting person, if I were in charge of a tech company I think I'd hire him!

Martin, if you think about making an MPC encoder filter, please wait for SV 7.5. Frank made clear to me that SV7 files are DEFINITELY no good for muxing, be it via DirectShow or anything else.

I am bugging Frank on a daily basis now to make a SV7 to SV 7.5 trancoding tool, doing nothing else but to repack SV7 files such that the audio blocks are independant from each other. We havent decided yet if SV 7.5 is going to get released with an encoder of its own, as Frank's plan is to make no new framing for SV 7.5 ( so its actually nonsense to call it 'SV' .. lol ), his idea was to simply output blocks from the transcoding tool, ideal for being muxed into other containers .....

After updating the decoder lib, it should be possible to play those fine on DirectShow, and from ANY container format supporting VBR and variable block length. I hope you guys will then update your DShow filter accordingly, we should talk before about what MEDIATYPE or MEDIASUBTYPE should be used for SV 7.5 then.

BTW : the SV8 alpha encoder is opensource and available from Frank's page, but unfortunately files created with it will not be compatible with any SV version existing, so its no big use right now .....

Is there any news?

AC3 5.1 is capped at 640kbps. Dolby Digital for DVD 5.1 is capped at 448kbps.



Great, another good point against DTS

Roberto do you know if the DVD's AC3 is re-encoded from the one @640kbps or is it encoded from a PCM 6-channel track?

I have no idea. But the AC3 hardware encoder (which, I guess, is used for encoding at studios) only accepts PCM imput. If they were to recompress the 640kbps stream they would have to first decode it anyway.

Some piece of history for you boys:

http://pub41.ezboard.com/fr3mixfrm6.showMe...opicID=32.topic



SV8 has been on the works since late 2000...

LOL

Hello Roberto,

That "piece of history" link I take it is your sardonic sense of humor at work?

References to outmoded lame command lines (and the man it was named after) and similar musings and concerns three years ago about mpc (they were calling it mp+ in the thread)

Ouch and double ouch!

Well, I sincerely dunno what you want to imply with it. I just meant that SV8 has been on the works for 3 years already.

In case you haven't noticed yet, I've been searching for old pieces of software for ReallyRareWares. One of the searches led me to that thread.

BTW: No, when I'm humourous, I generally use smilies.

ciao..

well.. that was a good one..

according to that posting..

so to be more accurate.. the mp+ have been worked on.. in that period.
what about mpc.. after the "name change"..

well, that post of r3mix proves him wrong again !
Still mpc (not mp+++ lol) needs only minor cpu power for en or de coding.

And as we saw, mpc was developed to best lossy codec regarding psy-model, quality of sound, at least for stereo.

So what, we have mpc 1.14, and it is just great, and, after 3 years r3mix' pessimistic post, mpc is greater than ever !

Now we should return IN-topic guys!

Are there any news about MPC SV 7.5 || 8 development?

I just sent an email to Frank now to hear where we are standing .... will get back to you here if i have any news to report ....

Look forward to more news, IMHO if he can really apply the benefits of mpc to aac that would be the way to go. AAC already has hardware support and will probably be the next big codec. I would Frank be able to dedicate some time to this if the community could convince Nero (or doubtfully apple) to hire him for a bit or part time (basically, would money make a difference)?

Why not working in the FAAC project? He could give it a boost!

Well, he WAS right about that...

We'll just have to see about that.

It seems pretty clear to me that Frank has lost his passion for developing Musepack. I would look elsewhere for futher development. It would have been nice if he could have got someone else to continue the project, that's whats good about team projects like lame.

any progress to that new official website?

it still says coming soon... only :/

This here will be the official website, until we can register musepack.org :

http://mpc.corecodec.org/

A high quality AC3 encoder with advanced psychoacustics would be great, I think the format is quite good, if you look at the mp2 specifications, the format is quite simple, even I understood the bitstream. While looking at ATSC A/52 I gave up to understand it, this format is far more complex and not as limited as mp2. Hardware decoders are already excisting for this format, but I think low-bitrate is still very interesting, not only in streaming, but in portables. If you want a very small portable without a harddisk and you want to have 50 hours music on it, you have to use low-bitrate. Also the storage possiblities are getting and bigger, the device will get smaller, so low-bitrate is still needed. I don´t think AC3 can beat AAC+SBR or MP3+SBR (maybe not even WMA) at ~64kbps, even with a perfect psy-model.

What are the alternatives? We have 3 other formats with hardware decoders (portable support) more or less yet: AAC (some devices), Vorbis (very few devices) and ...... WMA (quite many devices)
WMA, this crappy thing is supported by many portables and DVD Players already, and there is a open-source decoder for it. While reading the comments in the source it seems that M$ has stolen ideas of AAC and Vorbis and pulled them toghether in one format, there are comments like:
/* NOTE: We use the same code as Vorbis here */
/* decode exponents coded with LSP coefficients (same idea as Vorbis) */
/* NOTE: this offset is the same as MPEG4 AAC ! */
It seems to be a MDCT format with PNS. The question is, is it possible to write a good encoder being compatible with the M$-Decoders, are there bitrate limitations etc. Is the entire format crap or only the M$-implementation? If the format is good this could be a alternative to AC3.

Also AAC and Vorbis are interesting, I think Vorbis can be tuned much more, you could get much more out of it at all bitrates (yust remember Garf´s Floggy-Vorbis demonstration with 5kbps-stereo-Vorbis), and instead of creating a new MDCT-format (MusePack SV8/SV9), why doesn´t he improve Vorbis? It is most likely the most unrestricted format at all. Another new format need much time to get accepted by users and even more time for hardware support.
If he don´t like Xiph he can write a completly new encoder. (Wasn´t there a rumor once Frank is working on Vorbis??) If Vorbis won´t get improved with a higher quality encoder, faster decoder (is there still room to tune Tremor?), better compatibility with Windows (a new Ogg DirectShow Parser), it will be dying like VQF did and be overrun by WMA from the one and AAC from the other side.

I think Xiph did the wrong thing by starting Theora. This codec won´t be much better than On2 VP3 and won´t be able to compete with XviD, RV9, WMV9 or On2 VP6. They should have been concentrated on Vorbis to 80% and 20% to Tarkin. When time has come that H.264 can be used by the masses they had probably a good competor, Tarkin. And Vorbis now could beat AAC easily. Now they have two not-yet-finished (one not even really strated and one out-of time) Video-codecs, a Audio-codec with stopped developement it seems. Also Speex/FLAC should have been intigrated much faster in the entire project.

To come back to topic, a new MusePack won´t succeed in my opinion, no matter how good the quality is, and if he focus on several things like a AC3 encoder which slows down the developement of other the project the new format won´t succeed at all.

Well, it is not that unlimited - bit allocation must be stored in the bitstream, and there is no easy way of replacing the psymodel since spreading is hardcoded with so-called "attack/decay" (fastgain/slowgain) strategies.

MP2 was unfortunately limited by early decisions in the MPEG commitee - MPC is a good example how MP2 would behave if frequency-band-wise M/S coding and huffman coding were applied to MP2.



I think this is quite an optimistic view on it - technically, Vorbis only contains a subset of coding tools available in AAC - properly tuned, MPEG-4 AAC encoder should beat Vorbis easily (as shown at 128 kb/s tests) - at low bit rate range I must admit that for LC version of AAC nobody from the main developers was interested in lossy stereo - so at 64 kb/s test LC AAC was beaten by Vorbis because Vorbis used lossy stereo. Anyway, with HE-AAC and new algorithmic additions which are to be added in 2004, it is a very powerful coding system actually not that easy to beat.