Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: grums on March 16, 2011, 08:53:48 AM
-
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
-
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.
-
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
-
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.
-
OK, the archive is on http://dl.dropbox.com/u/6132290/clipplus-aac.7z -
Please notify me when it's downloaded.
-
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?
-
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.
-
(http://duke.edu/~mgg6/pics/error.png)
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.
-
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)
-
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://img854.imageshack.us/img854/7427/foobar.jpg
(http://img860.imageshack.us/img860/6277/rockbox.jpg)
http://img860.imageshack.us/img860/6277/rockbox.jpg
-
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)?
-
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.
-
So it's not only a Clip+ problem (targets running a similar processor type will exhibit the same symtoms)?
-
Probably all rockbox devices, although its possible the bug might be ARM specific, in which case coldfire players might not have it.
-
The spectral view was done with files which were decoded via sim. So, this is not ARM specific.
-
grums, are you able to compile rockbox? I might have a clue what causes this decoder failure and how to fix it. Easiest way to verify this possible fix is if you apply a minor code change and recompile rockbox (simulator is sufficient).
Fix:
in apps/codecs/libfaad/sbr_hfgen.c, line 195
change "#define ACDET_EXP 2" to "#define ACDET_EXP 3"
Edit: Bug report added to flyspray -> http://www.rockbox.org/tracker/task/12019
-
Later today or tomorrow I might be able to compile a 3.7.1 (Clip+ firmware) or (Clip+ simulator running on Linux as Guest in VMware Player for Windows) - that's my system.
(I'm not sure if the problem exists on that simulator, I haven't used it for listening purposes...)
I'll post the result.
-
The problem exists in the simulation as well. The same code and fixed point algorithm is used. Just do what is easier for you. Thanks for supporting the verification!
The proposed change is very local. You will only need to build and replace aac.codec.
-
I've applied the change to a RB 3.7.1 Clip+ simulator, and the clip I sent you seems to playback OK now.
Is there a short (plain english) explanation to the problem/fix?
Thanks, Ole
-
Good news!
I'll try explain the fix: About 6 months ago I reworked this code section. The fixed point implementation was totally wrong and just worked by chance. The multiplied and added data has a 31 bit fract part. To avoid overflow when adding up the data I shifted the data by >>2 before the calculation and shifted the results back accordingly. The simple fact is: >>2 was not enough.
I could explain in more depth why 3 is the correct value. But I will not go into more detail right now.
Anyway, thanks for testing!
Edit: Fixed with r29622 on Trunk and r29623 on v3.8 branch