Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#12221 - AAC files from BBC won't play on Clip+

Attached to Project: Rockbox
Opened by Jonathan Addleman (jaddle) - Monday, 08 August 2011, 14:51 GMT+2
Last edited by Andree Buschmann (Buschel) - Tuesday, 23 August 2011, 22:17 GMT+2
Task Type Bugs
Category Codecs
Status Unconfirmed
Assigned To No-one
Player Type Sansa AMSv2
Severity Low
Priority Normal
Reported Version Release 3.8.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

I downloaded some AAC files from the bbc, using the get-iplayer utility. The files play just fine on the computer, but on my rockboxed Clip+, they seem to freeze up the player entirely. I have to hold the power button for a long time to reset it. I just tried updating to rockbox 3.9, but I'm not seeing any difference with the new firmware.

When I play the file in mplayer, it gives the following info:
major_brand: M4A
minor_version: 512
compatible_brands: isomiso2
encoder: Lavf52.64.2
========================================================================Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
AUDIO: 44100 Hz, 2 ch, s16le, 48.0 kbit/3.40% (ratio: 6000->176400)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio))
========================================================================

I uploaded one of the broken files to my server at though it's a large file - about 30 megs. This is an entire radio broadcast. http://www.redowl.ca/files/BBC_Proms_-_2011_Proms_Chamber_Music_1._PCM_01_-_Bachs_Goldberg_Variations_b012llr2_default.m4a

All the m4a files I've downloaded seem to be broken like this though.

Any idea why these files aren't working? Is there anything I can do, short of transcoding them to another format?
This task depends upon

Comment by Andree Buschmann (Buschel) - Monday, 08 August 2011, 20:01 GMT+2
This file requires the allocation of 96924 entries for a m4a-related table with a size of 8 byte per entry (~760 KB). This amount of memory is not available on our targets or even simulator, hence the call of malloc() fails. Nevertheless the target should not crash, but only refuse to play the file.

Maybe I should check the behaviour of malloc() on my target. The sim refuses playback as intended.
Comment by MichaelGiacomelli (saratoga) - Monday, 08 August 2011, 20:26 GMT+2
I tried splitting this file with MP4box and while that prevents rockbox from crashing, it does not correctly decode the audio. There is a lot of background noise, the audio plays at several times normal rate, and PS stuff seems to be ignored resulting in a mono file (left channel only). Foobar2000 (also using libfaad) correctly decodes the file.

Test file:

http://duke.edu/~mgg6/rockbox/BBC_Proms_-_2011_Proms_Chamber_Music_1._PCM_01_-_Bachs_Goldberg_Variations_b012llr2_default_001.m4a

On a side note, the sim doesn't seem to print much debug info when it encounters an error. Perhaps it would make sense to have some of the error conditions DEBUGF when they encounter a problem.
Comment by Andree Buschmann (Buschel) - Monday, 08 August 2011, 23:43 GMT+2
Michael, the file you have linked plays fine in my nano2g simulator. No speed change, no noise.
Comment by MichaelGiacomelli (saratoga) - Monday, 08 August 2011, 23:49 GMT+2
I accidentally tested on the Clipv1, which I believe doesn't have PS enabled which is probably why it doesn't work :)

You're right, the Clip+ and Nano2G sound fine.
Comment by Jonathan Addleman (jaddle) - Tuesday, 09 August 2011, 01:26 GMT+2
This does fix the problem for me as well. I tested with 45 minute segments, and they seem to work. (in case anyone's wondering, I just did 'MP4Box -split 2700 filename.mp4'

It would be nice to be able to keep the files intact, of course, but this is much better (and quicker) than transcoding them all.
Comment by Andree Buschmann (Buschel) - Tuesday, 09 August 2011, 08:25 GMT+2
Do we want rockbox to behave like this (Not denying to play a SBR+PS even if this is switched off for the dedicated device)? Or should be change the behaviour to not even try to play such file?
Comment by Magnus Holmgren (learman) - Saturday, 20 August 2011, 11:37 GMT+2
I tested rewriting the file using mp4box (I just used the -ipod option to make it do something), and that way I reduced the size of the stco table (which I think is the problematic one) to about one tenth of the old size (96924 -> 9693). It plays in the simulator at least. And it will remove all tagging, but it beats transcoding, I guess.
Comment by Andree Buschmann (Buschel) - Tuesday, 23 August 2011, 21:36 GMT+2
Yes, the stco table requires too much memory. Using mp4box seems to be the best option.
Shall we close this bug report? I do not think we can fix anything here...
Comment by MichaelGiacomelli (saratoga) - Tuesday, 23 August 2011, 21:59 GMT+2
Theres no possibility of eventually reworking the MP4 parser to not need to store the entire table?
Comment by Andree Buschmann (Buschel) - Tuesday, 23 August 2011, 22:11 GMT+2
As far as I can remember from my last activities in this area you would need to allocate the memory at least once to read this stuff into data arrays to be able to further compress it. Don't ask about details, this is 4 months ago! :)
Comment by Magnus Holmgren (learman) - Tuesday, 23 August 2011, 22:33 GMT+2
It should be possible to avoid, but then you'd need to seek back and forth between two tables (stco and stsz), reading one in small chunks. It'd be better to do it during buffering, but that would require quite more work.
Comment by Andree Buschmann (Buschel) - Tuesday, 23 August 2011, 22:36 GMT+2
> It should be possible to avoid, but then you'd need to seek back and forth between two tables (stco and stsz), reading one in small chunks.

True, I dropped this approach due to the performance impact.

Loading...