Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Old RealAudio "cook" codec (Read 8560 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Old RealAudio "cook" codec

I know RealAudio was hated for it's ad ridden propertiary software , it is very old and was often ridiculed for its low sound quality. However, the samples of the "Cook" RealAudio here sound quite good http://samples.mplayerhq.hu/real/AC-cook/ , I mean for a early 2000s internet streaming codec, not compared to Opus or whatever. The 64 kbps and lower samples sound a lot better than mp3 at the same bitrate at least to me (you can listen in VLC). Hell, they sound better than many current AAC+ internet radios sound (I am not saying this legacy codec is superior to HE-AAC merely that some internet streams using AAC+ sound really bad).

How is that possible? Did cook use any bandwidth extension methods? I see even the 44 kbps file has frequencies up to 16 Khz and I know frequency response does not determine quality, but they are definitely more "trebly" than same bitrate mp3s. They are also stereo. I am not saying they are great, but they are listenable, surprising for an ancient codec with a very negative reputation. So what's up? What techniques did Cook use to compress audio? I also remember trying old RA internet radio as a kid and the quality seemed OK considering I was on dial-up.

Re: Old RealAudio "cook" codec

Reply #1 –
I worked on porting the Cook decoder to rockbox (along with MT).  It's a standard, barebones MDCT codec, pretty typical for that era (compare to WMA Standard or AC3).

It sounds pretty good because at those bitrates it's not that hard for a pure MDCT codec to sound pretty good, particularly if you're comparing to MP3. 

Re: Old RealAudio "cook" codec

Reply #2 –
Thanks but then why there is such variation in codec quality? A 48 kbps stereo AC3 file is unlistenable, hell, at 128 kbps it sounds duller. AC3 is a pure transform codec yet even worse than hybrid mp3. The Cook 44 kbps sample sounds better than 48 kbps wma 9.2 to me.

Re: Old RealAudio "cook" codec

Reply #3 –
It was pretty good at low bitrates for that time. I can remember I used RealProducer back in 1998/1999 to record some TV shows with my internal LifeView TV Tuner, haha.
Not sure what variant of RealAudio I used. I did experiment with MP3/WMA at that time, but got some horrible results at low bitrates.

Re: Old RealAudio "cook" codec

Reply #4 –
I knew some people back then who posited that RealVideo was the best codec for distributing QVGA (320x240) rips of cartoons.

Re: Old RealAudio "cook" codec

Reply #5 –
As a side question, QDesign codec was one of the earliest "low bitrate" ones, but it uses some agressive compression techniques that mean it has obvious artifacts even at 128 kbps. What "agressive compression" techniques does it use?

Re: Old RealAudio "cook" codec

Reply #6 –
It would be best to examine the decompressor found in FFMPEG, as that's the only available public source of information.

Re: Old RealAudio "cook" codec

Reply #7 –
Quote from: Neuron on
As a side question, QDesign codec was one of the earliest "low bitrate" ones, but it uses some agressive compression techniques that mean it has obvious artifacts even at 128 kbps. What "agressive compression" techniques does it use?

http://multimedia.cx/mirror/qdmc2.pdf

Looking at the decoder its DCT followed by the synthesis filter from MP3 (ffmpeg uses the same function for both).

Re: Old RealAudio "cook" codec

Reply #8 –
Thanks. There's one more format that has puzzled me, and while it is an unknown one I actually encountered it many times as it is a frequent format in games, Bink Audio. Looking on multimedia wiki it uses either DCT or RDFT instead of usual MDCT http://wiki.multimedia.cx/index.php?title=Bink_Audio . It also sounds very bad for the bitrate, with just a 12 Khz bandwidth at a bitrate slightly over 128 kbps and hearable artifacts despite this setting being labeled to be "perceptually lossless". However, it lacks severe clicking artifacts at block boundaries that were supposed to be the reason why most transform codecs use MDCT and not DCT. How come?

Re: Old RealAudio "cook" codec

Reply #9 –
Quote from: Neuron on
Thanks. There's one more format that has puzzled me, and while it is an unknown one I actually encountered it many times as it is a frequent format in games, Bink Audio. Looking on multimedia wiki it uses either DCT or RDFT instead of usual MDCT ...However, it lacks severe clicking artifacts at block boundaries that were supposed to be the reason why most transform codecs use MDCT and not DCT. How come?

"a frame is windowed with the previous frame; the size of the window is frame size / 16"

It's overlapping frames. MDCT does this too (by 50% instead of 1/16th), but the output from the MDCT has only half as much data as the input. This makes MDCT critically sampled (1->1 in->out) despite the 50% overlap.

This codecs' transform overlaps but it isn't critically sampled (it's 1->1+1/16), which means it has an additional overhead of 1/16th. This is how people made codecs before the MDCT was used.

Re: Old RealAudio "cook" codec

Reply #10 –
It is interesting because Bink Audio postdates the MDCT mp3. What does this archaic encoding method do in terms of coding efficiency? Is DCT better than RDFT or vice versa?

Re: Old RealAudio "cook" codec

Reply #11 –
Quote from: Neuron on
It is interesting because Bink Audio postdates the MDCT mp3. What does this archaic encoding method do in terms of coding efficiency?

As Garf said it's not as efficient. 

Re: Old RealAudio "cook" codec

Reply #12 –
Quote from: Neuron on
It is interesting because Bink Audio postdates the MDCT mp3. What does this archaic encoding method do in terms of coding efficiency? Is DCT better than RDFT or vice versa?

The way MDCT was used in MP3 is rather strange. They may have wanted to work around some patents. As said, it adds 1/16th (6%) extra overhead.

IIRC the DCT is generally considered to have better energy compaction than a RDFT, which is why video and image codecs use it too.

Re: Old RealAudio "cook" codec

Reply #13 –
I encoded some files with Rad Game Tools, but they only produce Bink DCT audio. Do older versions of Bink use RDFT audio?

Quote from: Garf on
The way MDCT was used in MP3 is rather strange. They may have wanted to work around some patents. As said, it adds 1/16th (6%) extra overhead.

However, Bink Audio postdates even AAC. The strange "Bink b" version that is incompatible with other newer ones is in Heroes of Might and Magic III, which is from 1999. Strange to use such a primitive audio codec.

Re: Old RealAudio "cook" codec

Reply #14 –
@Neuron : I believe you ignore one thing

1999:  Most people's computers =  Pentium II at speeds below 300 Mhz. (Note sure if this link at wikipedia is completely right about the Pentium III processor.)

Music in games in the mid 90s used to be MIDI based or very low quality wav. A few were using tracked modules (music made in realtime by the computer using samples and note patterns), but then, efforts were made on the composition itself and player software so that the computer resources weren't reduced too much. And then, there were also the games that had the music as Audio CD.

Pentium II and especially Pentium III enabled the use of technologies that speed up a lot the calculation of some type of instructions  (MMX and SSE), and this was of special use for audio and video. I still remember that there were ads saying that Pentium III was made for audio and video.

In such a scenario, the usage of an audio codec also implied an attention on its CPU usage. I remember a few games used Vorbis, and a few others used even WMA, but that was probably after year 2000.

So the codec might perform worse than necessary for these reasons.

Re: Old RealAudio "cook" codec

Reply #15 –
Quote from: [JAZ] on
In such a scenario, the usage of an audio codec also implied an attention on its CPU usage. I remember a few games used Vorbis, and a few others used even WMA, but that was probably after year 2000.

So the codec might perform worse than necessary for these reasons.

I don't think that is the reason.  The hybrid filterbank/DFT approach is probably not all that efficient.  In MP3 for instance, a majority of the decoder time is spent on the filterbank alone, and that step is essentially unnecessary if you go pure MDCT. 

Actually one of the striking things about early codecs like MP3 or ATRAC is that they were fairly CPU intensive, even compared to near-contemporary pure-MDCT codecs like WMA or AC3.

Re: Old RealAudio "cook" codec

Reply #16 –
Pentium 3 was already out in 1999, but I understand that point, hell, my family still had a 386. Does anyone know what version of RAD Video Tools produces RDFT Bink Audio files? I am interesting in the history of psychoacoustic codecs and I'd like to compare this incarnation of the codec to the DCT one. Indeo Audio might also be interesting.

Re: Old RealAudio "cook" codec

Reply #17 –
Quote from: saratoga on
I don't think that is the reason.  The hybrid filterbank/DFT approach is probably not all that efficient.  In MP3 for instance, a majority of the decoder time is spent on the filterbank alone, and that step is essentially unnecessary if you go pure MDCT. 

MP3 is best considered an oddity in this regard, the result of a process rife with industry politicking.

The speed argument may have merit. Although the MDCT is efficient I'm not sure if the 50% overlap doesn't mean an optimal implementation involves more CPU cycles than a codec with 6% overlap. Someone who's deeper into the respective maths might know.

Re: Old RealAudio "cook" codec

Reply #18 –
 
Quote from: Garf on
Quote from: saratoga on
I don't think that is the reason.  The hybrid filterbank/DFT approach is probably not all that efficient.  In MP3 for instance, a majority of the decoder time is spent on the filterbank alone, and that step is essentially unnecessary if you go pure MDCT. 

MP3 is best considered an oddity in this regard, the result of a process rife with industry politicking.

ATRAC is very similar to MP3 in this regard.  Actually I'm not aware of any hybrid subband/transform codecs that are particularly efficient, even compared to modern formats like AAC. 

In Rockbox ATRAC uses a fully assembly optimized filterbank (IIRC its something like 3 cycle per tap on ARMv5 using special DSP instructions) and the same MDCT as Vorbis/AAC/AC3/WMA:

http://www.rockbox.org/wiki/CodecPerformanceComparison

There are a lot of results for different devices and configurations which are interesting to look at, but there is one for the iPod Classic in the unboosted (normal) state where the memory and CPU clock are both the same frequency: 

26.10MHz for ATRAC vs. 17.64MHz for Vorbis or 20.79MHz for WMA.

I'm sorry I don't have more detailed numbers just for the filterbanks and MDCTs, but I lost them at some point over the years. Still you can get an idea of how expensive a hybrid approach really is. 

Quote from: Garf on
The speed argument may have merit. Although the MDCT is efficient I'm not sure if the 50% overlap doesn't mean an optimal implementation involves more CPU cycles than a codec with 6% overlap. Someone who's deeper into the respective maths might know.

There is a neat algorithm for handling it by exploiting the symmetry of the transform:

http://git.rockbox.org/?p=rockbox.git;a=blob;f=lib/rbcodec/codecs/lib/mdct.c;h=777aec4a55bbfe686ecc4cb06ad361a36882cf0d;hb=HEAD#l429

Alternatively, even just the naive way of computing the full thing and overlapping is still pretty efficient.  For a while we did that on Vorbis/WMA, and both were still faster than MP3 or ATRAC.

FWIW, in libmad on ARM, writing almost everything in assembly, the MDCT takes about 25% of the runtime, the filterbank about 50%, and everything else in MP3 just 25%.  The problem is that you are basically passing every sample through two frequency transforms, which is slower than just using one.  You save some cycles because the MDCT transforms are of shorter length, but complexity of the MDCT is not much worse than linear, so the savings is small relative to the cost of the filterbank.