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: BSAC implementation of the standard (Read 2316 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

BSAC implementation of the standard

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: [Select]
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: [Select]
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.

BSAC implementation of the standard

Reply #1
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: [Select]
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: [Select]
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.