Help - Search - Members - Calendar
Full Version: Scale factor bands
Hydrogenaudio Forums > Lossy Audio Compression > AAC > AAC - Tech
Heiko242
Does anyone know why, given a sampling rate of 48kHz per second for the .wav-file,
the long MDCT window in AAC has 49 scale factor bands and the short MDCT window has 14 ?
Is there a rule, based on critical bark bands or so, how to calculate the number of
scale factor bands, or is it a simple heuristic number? If I want to use an MDCT with,
say, 512 channels (instead of 1024, or 128) what would be the criteria to choose the number of scfbs?
SebastianG
QUOTE(Heiko242 @ Apr 22 2008, 13:50) *

Does anyone know why, given a sampling rate of 48kHz per second for the .wav-file,
the long MDCT window in AAC has 49 scale factor bands and the short MDCT window has 14 ?
Is there a rule, based on critical bark bands or so, how to calculate the number of
scale factor bands, or is it a simple heuristic number? If I want to use an MDCT with,
say, 512 channels (instead of 1024, or 128) what would be the criteria to choose the number of scfbs?

It's a trade-off. The more scalfactors you have the more bits you need to code them which can't be spent anymore on the actual samples. Obviously there's a sweet spot somewhere. To cope with attacks and fight preecho you may use several short block groups (say 3) with different scalefactors within a frame, so you end up coding 3x14 scalefactors instead of 1x49. Thus you traded high spectral resolution of the noise floor for high temporal resolution.

Apart from that I'm clueless.

HTH,
SG
Gabriel
and of course, differentially coding the scalefactors helps to reduce their cost (mp3 vs aac)
Woodinville
QUOTE(Heiko242 @ Apr 22 2008, 04:50) *

Does anyone know why, given a sampling rate of 48kHz per second for the .wav-file,
the long MDCT window in AAC has 49 scale factor bands and the short MDCT window has 14 ?
Is there a rule, based on critical bark bands or so, how to calculate the number of
scale factor bands, or is it a simple heuristic number? If I want to use an MDCT with,
say, 512 channels (instead of 1024, or 128) what would be the criteria to choose the number of scfbs?


Well, let's see.

There are some rules:

1) All scalefactors have to have a multiple of 4 lines in them
2) All scalefactors have to have no more than (I think 32?) lines in them, except the final band over 20kHz
3) All scalefactor bands should be close to ?1? critical band. (I've forgotten,but it was some %age of a critical band.)

I think those were the original criteria, at least.

QUOTE(Gabriel @ Apr 23 2008, 00:01) *

and of course, differentially coding the scalefactors helps to reduce their cost (mp3 vs aac)


Very much so, because of the Huffman coding.

Do you have any idea how hard a particular German organization fought against differential coding of scalefactors and Huffman coding of scalefactors.

Did you know that the scalefactor Huffman table is defective, and based on an unnecessary limit in the rate loop of the reference model?

tongue.gif
Gabriel
QUOTE(Woodinville @ Apr 25 2008, 19:14) *

Do you have any idea how hard a particular German organization fought against differential coding of scalefactors and Huffman coding of scalefactors.

On a related subject, perhaps one day you'll explain us what happened to the upper scalefactor within mp3. Did anyone stole it, or was it lost somewhere when traveling to an mpeg meeting?
Woodinville
QUOTE(Gabriel @ Apr 25 2008, 13:23) *

QUOTE(Woodinville @ Apr 25 2008, 19:14) *

Do you have any idea how hard a particular German organization fought against differential coding of scalefactors and Huffman coding of scalefactors.

On a related subject, perhaps one day you'll explain us what happened to the upper scalefactor within mp3. Did anyone stole it, or was it lost somewhere when traveling to an mpeg meeting?



Oh my ghu. You don't want to know.
Heiko242
QUOTE(Woodinville @ Apr 25 2008, 12:14) *


Well, let's see.

There are some rules:

1) All scalefactors have to have a multiple of 4 lines in them
2) All scalefactors have to have no more than (I think 32?) lines in them, except the final band over 20kHz
3) All scalefactor bands should be close to ?1? critical band. (I've forgotten,but it was some %age of a critical band.)

tongue.gif


Thank you very much.

I once read that it was common for the great mathematicians of the past, Gauss, Fermat, deMoivre, Leibnitz,
etc. to correspond particular formulas, which solve a mathematical equation, to their colleagues but they
did not describe how they achived their solutions. Everyone had to figure out by himself , how the
other one solved the problem.

Working on "the science" of audio coding sometimes reminds me of these times. unsure.gif
Woodinville
QUOTE(Heiko242 @ Apr 29 2008, 00:48) *

QUOTE(Woodinville @ Apr 25 2008, 12:14) *


Well, let's see.

There are some rules:

1) All scalefactors have to have a multiple of 4 lines in them
2) All scalefactors have to have no more than (I think 32?) lines in them, except the final band over 20kHz
3) All scalefactor bands should be close to ?1? critical band. (I've forgotten,but it was some %age of a critical band.)

tongue.gif


Thank you very much.

I once read that it was common for the great mathematicians of the past, Gauss, Fermat, deMoivre, Leibnitz,
etc. to correspond particular formulas, which solve a mathematical equation, to their colleagues but they
did not describe how they achived their solutions. Everyone had to figure out by himself , how the
other one solved the problem.

Working on "the science" of audio coding sometimes reminds me of these times. unsure.gif


During the time of making the standard, not many people thought this information was important, in fact most people didn't want to use that many scalefactors, having misunderstood the tradeoff between side information and main information.

The maximum size of the scalefactor is directly related to the stereo/mono switching method. Is this a surprise?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.