AAC beaten at low bitrates, why? Options

[Gecko]

Originally posted by Frank Klemm
Subband coding is NOT patented. 
Read patents very very carefully or don't read it.
Perceptional noise substitution is also NOT patented.
When reading patents it is necessary to find out what is EXACTLY patented.

Sorry, I am not able to understand documents where a large amount of the sentences spans more than 40 lines of text. Those of you who can, can read the patent here http://www.depatisnet.de. English pages are available. Search for Patent "EP 0400755 B1". After reading parts of the description and of the claims, I don't see why musepack does not fall under this patent. Please don't tell me to read the whole thing (and understand it ). Are you aiming at the transmitter/reciever part? Imho this is covered in the claims.
Usually a court will decide what exactly is patented or not .
What is the difference between the mechanisms described in the patent and the ones implemented in mpc?
Where does mpc use patents then?

[Gecko]

Subband coding is NOT patented
---
Philips subband patent can be removed

Now I'm confused. ??? I'm sorry if I didn't use the proper, exact terminology.
Way back in third grade a guy once said: "I didn't spit at her, and besides, I missed!"

[Garf]

Originally posted by Gecko
Now I'm confused. ??? I'm sorry if I didn't use the proper, exact terminology.
Way back in third grade a guy once said: "I didn't spit at her, and besides, I missed!"

I think what he's saying is that subband coding in itself is not patented, but the specific way it's done in Musepack now is.

--
GCP

[Mac]

Back to my original point... currently AAC is pretty bad at low bitrates, and MPC is worse than AAC, I'm not sure how MPC could stick around as a major format because it can't get that much better at low bitrates, which is how alot of stuff is transferred on the internet. (eg, I encode at -internet (~70k) for giving my music to friends, would like to use -thumb (~50k), but that just sounds horrible!)

Do you reckon -thumb would start sounding reasonable with the AAC+SBR? I find -internet is high enough quality to listen to without being continually reminded that its nasty quality.

[wkw]

I think the short-block mode of AAC is giving the problem. Long Block is more efficient than short block. In fact, for most complex musical clips, the PE measurement is just about 600 ~ 800 bits but when there is a lot of signal transients, the AAC algorithm has to switch to short block, which requires 2~3 times more bits than long block. Worse, the length of the long block mode, 2048 time samples would mean that when switch to short-block, more time audio sample would have to be coded in short-block. In fact, the AAC short block is more inefficient than the MP3 short block
mode. AAC requires 8 short block, 256 time samples each whereas MP3 only requires 3 short block, 384 time samples each. Also, MP3 specs allowed block switching on a frequency basis, eg: frequency above 2Khz coded in short-block while anything below can be coded in long-block. This is a feature not available to AAC, not even for the Gain-Control tools.

For long block, there is a theory that states that maximum block length for most efficient coding is about 2048 time samples. Anything above or below this length would require more bits. There is alot of active research in abolishing the need to switch to short block such as switching to wavelet filter banks or the Gain Control tools during signal transients.

Also, there is alot of research into noise-tone classification model which provides even more coding gain which I believed the MP3Pro is based on. However, how good the audio quality at Hi-Fi level is unclear. I tested MP3Pro on the castanets clip and it seemed to contain some irritating artifacts. I would not classify MP3Pro as a Hi-Fi / CD level encoder.


wkw

[wkw]

I think the short-block mode of AAC is giving the problem. Long Block is more efficient than short block. In fact, for most complex musical clips, the PE measurement is just about 600 ~ 800 bits but when there is a lot of signal transients, the AAC algorithm has to switch to short block, which requires 2~3 times more bits than long block. Worse, the length of the long block mode, 2048 time samples would mean that when switch to short-block, more time audio sample would have to be coded in short-block. In fact, the AAC short block is more inefficient than the MP3 short block
mode. AAC requires 8 short block, 256 time samples each whereas MP3 only requires 3 short block, 384 time samples each. Also, MP3 specs allowed block switching on a frequency basis, eg: frequency above 2Khz coded in

[guruboolez]

Originally posted by wkw
I tested MP3Pro on the castanets clip and it seemed to contain some irritating artifacts. I would not classify MP3Pro as a Hi-Fi / CD level encoder. 

mp3pro bitrate limitation is very low. At this bitrate, no codec can claim CD-quality. At least for a lot of samples, and for most music.
But a agree with you : mp3pro spec, based on mp3 spec, is limiting the theorical quality on transient signal. It is not really CD quality, even on -b 640 --freeformat.


EDIT : I don't understand anything on lossy/lossless specs. I just experiment these preecho problem on mp3/mp3pro samples.

[Mac]

Bah, I hate it when this happens. I was told off for getting cross-subject in one of my threads, so keep ya MPC whatnots to yoursleves!

If the shortblock is inefficient, could it be improved drastically? Or maybe it's like that for a reason (eg, giving better quality than mp3 shortblocks ever did)

[JohnV]

Originally posted by niktheblak
Now that I'm at it, why does everyone keep saying that codecs using DCT are the only "transform" codecs whereas codecs like MPC (using FFT) are "subband" codecs with nothing to do with transforms at all?

"Subband" encoding does use discrete Fourier transform. "Transform" encoding uses discrete cosine transform. Mathematically speaking, these transforms are nearly identical, with cosine transform being nothing but a cosine-termed (is this the correct english expression?) Fourier series (Fourier transform without the cosine, or ImX, part). Cosine transform just makes energy representation a little easier than Fourier transform.

Because the FFT in subband coders like MPC is done in psychoacoustics calculations which is a separate process. Psychoacoustics defines the masking threshold which is used in the quantization phase. With subband codecs transform coefficients are not used in actual encoding/quantization. Transform codec like MP3 also uses FFT (normally) for psychoacoustics, but as I said it's a separate process...

MPC quantizes the time-domain samples (based on the masking threshold given by psychoacousic analysis), not any frequency transform co-efficients like transform coders.

[JohnV]

Thread splitted.
Some MPC specific messages have been moved to the MPC general forum:
http://www.hydrogenaudio.org/forums/showth...=&threadid=3068

[Ivan Dimkovic]

wkw,

AAC has very efficient mode of grouping of 8 short blocks into groups which in most cases reduces necessary bits by a significant margin.

Basic AAC does not have SBR tools implemented in, so for compare with mp3pro we would have to wait AAC+ (MPEG-4 V3) and see how does it match with mp3pro. CT (codingtechologies) already stated that AAC+ is superior to mp3pro.

[Frank Klemm]

Originally posted by JohnV
Because the FFT in subband coders like MPC is done in psychoacoustics calculations which is a separate process. Psychoacoustics defines the masking threshold which is used in the quantization phase. With subband codecs transform coefficients are not used in actual encoding/quantization. Transform codec like MP3 also uses FFT (normally) for psychoacoustics, but as I said it's a separate process...

MPC quantizes the time-domain samples (based on the masking threshold given by psychoacousic analysis), not any frequency transform co-efficients like transform coders.

Subband and transform encoder do a time decimation and split the signal into multiple
bands. I would call a subband filter a "multiple overlapped transform".


Subband encoders: multiple overlapped transform
- filter length: 512 (first zero cross at +/-55.9)
- decimation: 32
- overlap count: 16

Transform encoders: dual overlapped transform
Long block AAC:
- filter length: 2048 (first zero cross at +/-1023)
- decimation: 1024
- overlap count: 2

Short block AAC:
- filter length: 256 (first zero cross at +/-127)
- decimation: 128
- overlap count: 2

[wkw]

Originally posted by Ivan Dimkovic
wkw,

AAC has very efficient mode of grouping of 8 short blocks into groups which in most cases reduces necessary bits by a significant margin.

Well, from my observation on the sum PE measurement of 8 short-blocks with PE of 1 long-blocks, it seemed that even window grouping of short blocks will not reduced the bits required to code in short blocks to the level of long block mode. Window grouping in my opinion only reduces the "side info" of short-block.

wkw