Created attachment 6524 [details]
Example AAC/.m4a audio file that won't decode natively

This is possibly a duplicate of bug 15608. You would need 7.5.0 r6678 or newer firmware to test if that resolves the problem.

(In reply to comment #2)
> This is possibly a duplicate of bug 15608. You would need 7.5.0 r6678 or newer
> firmware to test if that resolves the problem.

Thanks, but I'm now up the creek having attempted this test.

I downloaded Squeezeserver 7.5.0 Beta which installed and ran OK.  Powered on the Radio, which immediately offered the firmware upgrade to 7.5.0 r88?? (I didn't record the last two digits).  I started the firmware upgrade which after around 10 minutes has now hung on 99% complete.  Radio is now totally unresponsive to all controls and I daren't unplug for fear of 'bricking' it.  Squeezeserver is now reporting 'Total players recognised: 0'.

The only clue to possible problems in the server log file are several lines thus:

[10-02-20 23:44:51.3993] Slim::Networking::SqueezeNetwork::_init_error (209) Unable to login to mysqueezebox.com, sync is disabled: Invalid mysqueezebox.com username or password. (http://www.test.mysqueezebox.com)#

I have a valid account on mysqueezebox.com and also created one on test.mysqueezebox.com in case this was significant.  I can sign into both of these accounts manually.

Help please!

Please ignore the panic above and the misremembered firmware version number - an overnight power glitch reset the Radio anyway and I was able to try the firmware update again which was successful.

So the Radio is now on Firmware version 7.5.0 r8445, working to Squeezebox Server 7.5.0 r30216.

However, the problem AAC files, including the attached example, still will not play natively on the Radio.  Error message is again 'Can't Open File' (although it's now presented in a nice box on the screen!).  It seems therefore that the newer firmware has not fixed this bug.  Everything else seems fine.

(I tested by restoring the AAC-AAC and MPEG-4-AAC settings to 'Native' decoding on Settings/Advanced/Filetypes)

Thank you for your testing. I will investigate further,

This file contains the Media Data Box (mdat) before the file metadata in the Movie Box (moov). This is an unusual ordering which we cannot support as the underlying MP4 file is streamed unaltered to the player. The player needs the metadata before it can start decoding the audio data and does not make a temporary storage of the whole stream in order to facilitate this; it requires that Movie Box precedes the Media Data Box and that the samples in the Media Data Box are in order (although not necessarily contiguous).

The MP4 standard (ISO/IEC 14496-12:2008: Information technology — Coding of audio-visual objects — Part 12:ISO base media file format) envisages that a server will convert an MP4 file to some other format before streaming it, and Squeezebox Server can indeed be configured to do this (by disabling native playback of MP4 files; AAC and ALAC). Squeezebox Server does not currently contain facilities to stream AAC or ALAC content from an MP4 file using some other stream envelope format.

This issue is discussed at http://multimedia.cx/eggs/improving-qt-faststart (and elsewhere). It appears that qt-faststart will reorder the contents of the file as necessary to make it streamable. I suggest that you use it on any MP4 files you create with ffmpeg.

In the original Description above, you talk about "sourcing audio files from iTunes" and then say "I created the files it can't decode with ffmpeg". Can you confirm that none of the problem files come from iTunes?

Thanks for your investigation and explanation.  I think I understand the nature of the problem now.

For clarification:

1.  The problem files were all coded by ffmpeg, NOT iTunes/Quicktime.

2.  My reference to 'sourcing files from iTunes' was a little sloppy.  What I should have said was I simply use the iTunes library to manage the problem files originally coded by ffmpeg (in addition to using it to manage all my other music files coded by iTunes/Quicktime itself which play natively on the Radio with no problem).

It's a shame that ffmpeg doesn't default to writing mp4 files in the 'more usual' metadata order that would permit streaming!  I'll take a look at the link you suggest and see how easy it is to put all my problem files through a reordering process.

Don't know if you wish to pursue this any further, but ...

... I tried qt-faststart on my original problem file, which seemed to work OK, and according to its description should have moved the 'moov' to the start of the file and thus allow streaming.

However, the Radio still won't decode this natively.

I have attached the new file which qt-faststart created.  Apologies, I don't have any software to allow me to look at the mp4 file structure, and even if I had I would be well out of my depth.  If you were able to take a look I would be very interested - did qt-faststart not do what it said on the tin, or is there another underlying problem?

As you can see my naming convention for this file was over-optimistic!

Thanks again for your help on this.

Created attachment 6552 [details]
AAC/.m4a audio file modified by qt-faststart, still won't decode

Ok, thanks for this. This is a separate problem. I have opened bug15809 to cover this issue.

I am closing this bug but note that bug 15809 is also relevant. Bug 15608 may also be relevant to users experiencing similar problems.