Clip+ playback: AAC/SBR 82 kbit/s - high pitch sound added

[grums]

I've encoded a track using neroaacenc -q 29, resulting in an AAC/SBR file with kbitrate 82.
When I playback on the Clip+, some high-pitched sound is added on top of a saxophone.
Problem is on RB 3.7.1 and 3.8.
No problem with playback on a Creative Zen, or Windows foobar2000 (through Behringer UCA202 DAC), or on Clip+ with forced LC encoded track.
Problem is also on Windows Clip+ simulators (using the DAC).
I've used speakers and several different phones, same result.
I have a .7z archive with 3 18 sec soundfiles, encoder and doc.

Ole

[Buschel]

This sounds like an issue with the software decoder itself. Can you provide a sequence (ony a few seconds) to further analyze this? I will need the original pcm, the encoded m4a, the foobar decoded pcm and the clip+ simulation decoded pcm.

[grums]

Sorry about my ignorance, I'm not exactly an expert on this: please hint me about how to provide the following:

• the foobar decoded pcm (maybe I can find out myself)
• the clip+ simulation decoded pcm - hmmm...

Ole

[Buschel]

No problem, let me try to explain.

1) You will be able to decode the m4a file to a wav-file. Just provide this wav-file.
2) I can do this by myself, if you provide the m4a. Rockbox has the possibility to decode any audio file to wav and write this to flash or HDD.

[grums]

OK, the archive is on http://dl.dropbox.com/u/6132290/clipplus-aac.7z -
Please notify me when it's downloaded.

[Buschel]

Downloaded, will take a look at them tomorrow earliest. Thanks so far!

Edit: There definately *are* visible differences when comparing the spectral representation of the foobar-decoded file against rockbox's output. Do you have a chance to give a bit more information about when this came in? e.g. with which rockbox version?

[saratoga]

Trying the current build I get pretty similar output to foobar.  Theres some difference (RMS error is ~16 PCM levels).  Interestingly the error isn't white, its concentrated in the SBR bands (although it looks fairly uniform there), but I'm not sure thats wrong.  IIRC the SBR signal contains a random component. 

[saratoga]

http://duke.edu/~mgg6/pics/error.png

FFT of the error signal plotted on a dB scale.  Not really sure what to make of it, the error doesn't line up all that well with the SBR region after all.

[grums]

Interesting!
I can't help you much with history, as my first version was 3.7.1.
(I don't listen to that record very often, but funny enough: on another track from it, with low music intensity and slow blue piano notes, OGG encoding at ~80 kbits/sec suffers, even with the newest encoders)

[Buschel]

The images I have linked show a spectral view of the foobar and rockbox decoded files. You can easily spot the differences. It only seems to affect higher frequency components. A first quick guess from my side is that this might be a bug in the hf_adj/hf_gen part of the decoder...


http://img854.imageshack.us/img854/7427/foobar.jpg


http://img860.imageshack.us/img860/6277/rockbox.jpg

[grums]

OK, I can see they're quite different - does it make any sense to compare with the the source code for the foobar decoder (I assume it's available)?

[saratoga]

OK, I can see they're quite different - does it make any sense to compare with the the source code for the foobar decoder (I assume it's available)?

Yes, its the same one we're using. 

[grums]

So it's not only a Clip+ problem (targets running a similar processor type will exhibit the same symtoms)?

[saratoga]

Probably all rockbox devices, although its possible the bug might be ARM specific, in which case coldfire players might not have it. 

[Buschel]

The spectral view was done with files which were decoded via sim. So, this is not ARM specific.