• Status Unconfirmed
  • Percent Complete
  • Task Type Bugs
  • Category Codecs
  • Assigned To No-one
  • Operating System Sansa AMSv2
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.8.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by jaddle - 2011-08-08
Last edited by Buschel - 2011-08-23

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

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.

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 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.

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:

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.

Michael, the file you have linked plays fine in my nano2g simulator. No speed change, no noise.

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.

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.

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?

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.

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…

Theres no possibility of eventually reworking the MP4 parser to not need to store the entire table?

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! :)

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.

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.

porjo commented on 2013-08-17 15:52

I'm having trouble playing certain m4a files on my Sansa Clip Zip and I believe it may relate to this bug. In my case I download an FLV file from youtube for the following video: , then split out the audio using ffmpeg: "ffmpeg -i inputfile.flv -vn -acodec copy outputfile.m4a"

encoder : Lavf52.64.2
Stream #0.0(und): Audio: libfaac, 22050 Hz, mono, 23 kb/s

The resulting m4a file does not play on Rockbox - it just skips to the next file. If I extract the audio stream and re-encode (rather than copy) it produces a file that will play on Rockbox.


Available keyboard shortcuts


Task Details

Task Editing