rickwookie wrote: > Ok, I've run the file through ffmpeg (a newer version on my Windows > machine) with the stream copy options as you suggested, and sure enough > that file plays fine. However, I'm confused as to why what is > essentially just the embedded cover art is causing the problem. Lots of > the other m4a files I have include embedded cover art and they still > play fine. > > What I then tried is extracting the cover art from the original "bad" > file (I use Mp3tag) as a jpeg, then adding it back to the new "good" > file as the front cover image again with Mp3tag. Looking at that file > then with ffmpeg I can see that once again I have the second stream > (#0:1) as an mjpeg, but now, the file plays fine too! The filesize is > ever so slightly smaller than the original now: 1,990,794 bytes vs > 1,991,289 bytes (so just 505 bytes smaller). > > I'm now going to try to use ffmpeg again to copy BOTH streams (if I can > work out the command syntax) to see if that will strip out whatever > those mystery 505 bytes are that is causing the tracks not to play nice > with faad. > > I've DM'd you a link to the fixed file for comparison
The problem is that it is not a embedded covert which is metadata. It has been stored as a single stream which has a video and audio component - just like a full movie. faad was initially just a AAC decoder from ADTS fromatted streams and then a partial MPEG4 format decoder element was added later but the decoding assumes just a simple audio stream. So the problem is the limitation of the implementation of faad. The choice is to fix fadd or use ffmpeg instead of faad. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=111719 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
