Help - Search - Members - Calendar
Full Version: BSAC implementation of the standard
Hydrogenaudio Forums > Lossy Audio Compression > AAC > AAC - Tech
Sebxoii
Hi everyone,

I'm desperately trying to add the BSAC decoding functionalities to my AAC decoder and I'm facing a weird problem.

Since I've started this, I've noticed that there is a couple of typos in almost every paragraph in the standard. This isn't much of a problem on itself, but this makes me cautious about the rest, meaning the algorithm/syntax.

I was in the middle of calculating the help variables (layer_end_index, cband , etc...) and actually found a few mistakes in the algorithm/pseudo-code => Chapter 4.5.2.6.2.5.

In the end, I still don't end up with the same values as the ISO's reference code. This comes as a surprise since I did nothing more than copy-paste the pseudo-code and correct the obvious typos.

I've tried comparing the standard pseudo-code to the one actually implemented in the reference, but the differences are so important that it makes it impossible. Still, it seems to me that a couple of tests are missing.

For instance :
When computing layer_end_sfb : the test stating
CODE
if (layer_end_index[layer] <= swb_offset_short_window[fs_index][sfb] * window_group_length[g])

should actually take into account that there can be "long_windows", and that the "sfb " index should be "sfb+1"

also, when computing layer_end_index, layer_end_cband :
CODE
end_cband[g] = layer_end_cband[layer] = cband+1;
end_index[g] = layer_end_index[layer++] = (cband+1) * 32;

it seems weird that "end_index" and "end_cband" would be modified since they were computed 10 lines above when determining "slayer_size".

still in the same pseudo-code :
Shouldn't there a test stating that the value of "layer_end_index[layer]" cannot be higher than the value of "end_index[g]" (as it's done in the reference code).

Sorry for the long introduction, but I wanted to state the facts before asking my stupid question :

Do I have an outdated version of the standard still containing many mistakes ? (I think I have one of the latest version with the amendment containing the BSAC extensions...and haven't seen any pertinent corrections of the ISO's website)
Did I miss a small detail when computing those variables ?
Or am I just completely lost ?

Thanks in advance to anyone who'll be able to point me in the right direction.

Kind regards,
Sébastien.
Sebxoii
Hi again,

I've just come across a stunning example of what I was trying to explain in my previous post. I hope this will help you understand my predicament.

Here's the ISO's standard pseudo code :
CODE
if (fs == 44100 || fs == 48000)
{
    if (end_index[g]%32 == 0)
        end_index[g] += 8;
    else
        end_index[g] += 12;
}


Here's the ISO's reference implementation pseudo-code :
CODE
case 44100:
        end_freq[reg] += 8;
        if ((end_freq[reg]%32) != 0)
          end_freq[reg] += 4;


From what I can see, in the standard pseudo-code, if end_index%32 == 0, I'll be adding +8 to the its value.

In the ISO's reference code, you'll be adding +8 to its value, even if end_freq%32 == 0. Then of course,(end_freq+8) cannot be equal to 0, so you'll be adding an extra +4.

I just faced this problem with "end_index = 128", in one case the end result is 136, in the other 140.

I suppose only one of them can be correct, which is it ?

Thanks in advance.
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-2009 Invision Power Services, Inc.