SanDisk Clip Sport/Jam is buggy, support generating "simpler" mp4 files that can be played by it.

[bat999]

Hi
m4a files created by FFmpeg aren't supported by SanDisk Clip Sport/Jam.
I've attached 3 files.

1 nero.m4a
This plays OK.
Created with neroAacEnc version 1.5.4.0
neroAacEnc -if foo.wav -of nero.m4a

2 FFmpeg.m4a
This doesn't play.
Created with FFmpeg ffmpeg version git-2015-10-28-cceed83
FFmpeg -i foo.wav -c:a aac -strict -2 FFmpeg.m4a

3 nero2.m4a
This doesn't play either (nero file re-muxed by FFmpeg).
ffmpeg -i nero.m4a -c copy nero2.m4a

So I think that it is not FFmpeg's aac encoder that is causing the problem, but maybe the muxing into m4a by FFmpeg.

My operating system Ubuntu-12.04.
The mp3 player is Clip Jam 8GB model number SDMX26-008G-G46K

[bat999]

Hello again.
I've done another experiment.

I converted from wav to aac using FFmpeg.
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac

Then I muxed it with MP4Creator Version 1.6.1d
mp4creator -create=foo.aac mp4creator.m4a

The result file plays OK in the Clip Jam player.
I've attached it above.

So again, I think it's not FFmpeg's aac encoder that is the problem, but it's the muxing into m4a by FFmpeg.

[relaxed]

See if this works:

ffmpeg -i foo.wav -c:a aac -strict -2 -f ipod output.m4a

[bat999]

ffmpeg -i foo.wav -c:a aac -strict -2 -f ipod output.m4a

The output file won't play on the Clip Jam :-(

[bat999]

Hi
I did another experiment.
I converted from wav to m4a using faac-1.28.
faac -o faac.m4a foo.wav
This file plays OK.
I've attached the file.

m4a files created by FFmpeg ffmpeg version git-2015-11-13-6f520ce don't play.

[bat999]

Hi
I did another experiment.
I converted from wav to m4a using fdkaac 0.6.2.
fdkaac -o fdkaac.m4a --bitrate-mode 3 foo.wav
This file plays OK.
I've attached the file.

[Carl Eugen Hoyos]

Looks like a duplicate of ticket #2809 to me.

[bat999]

Hi
Yes, could be the same problem.

My Sansa Clip Jam seems to also play files that have been muxed by MP4Box - GPAC version 0.4.6-DEV-rev.
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; MP4Box -add foo.aac -new MP4Box.m4a

[bat999]

Hi
I've repeated the tests.
The file created and muxed by FFmpeg won't play in my Sansa Clip Jam.
The files created by neroAacEnc, faac, fdkaac, play OK.
The files created by FFmpeg and muxed by MP4Creator and MP4Box play OK.
I've extracted the moov data from all the files with AtomicParsley.
Maybe somebody can analyze this data to help determine why the FFmpeg muxed file won't play.
The files and the moov data are inside the results.tar.xz file attached.

Programs used.
FFmpeg version git-2015-11-20-9747219
neroAacEnc version 1.5.4.0
faac version 1.28
fdkaac version 0.6.2
MP4Creator version 1.6.1d
MP4Box - GPAC version 0.4.6-DEV-rev
AtomicParsley version: 0.9.6

Commands used.
ffmpeg -i foo.wav -c:a aac -strict -2 2FFmpeg.m4a
neroAacEnc -if foo.wav -of 2nero.m4a
faac -o 2faac.m4a foo.wav
fdkaac -o 2fdkaac.m4a --bitrate-mode 3 foo.wav
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; wine mp4creator -create=foo.aac 2mp4creator.m4a
ffmpeg -i foo.wav -c:a aac -strict -2 foo.aac; MP4Box -add foo.aac -new 2MP4Box.m4a
AtomicParsley filename.m4a -T

[bat999]

Hi
I've done another experiment.

With avconv...
avconv version v12_dev0-2198-g489e6ad, Copyright (c) 2000-2015 the Libav developers

built on Dec 24 2015 16:20:43 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)

avconv -i foo.wav -strict experimental -c:a aac avconv.m4a
The file plays OK in my Sansa Clip Jam.
:-)

With FFmpeg...
ffmpeg version git-2015-12-24-4707497 Copyright (c) 2000-2015 the FFmpeg developers
ffmpeg -i foo.wav -strict experimental -c:a aac ffmpeg.m4a
The file does not play in my Sansa Clip Jam.
:-(

There must be some difference between the muxer in avconv and the muxer in FFmpeg.
I've attached the two files avconv.m4a and ffmpeg.m4a.

[bat999]

Yes, the avconv file does play OK, but that's because it's a very short clip.
Only avconv m4a files <= 40 seconds duration will play in Sansa Clip Jam.
With mp4creator muxer it will play files <= 30 minutes.
So avconv isn't the solution after all.

There are many ipod options with command "ffmpeg -h muxer=ipod".
But I don't feel inclined to plough through them blindly.
Maybe the AtomicParsley -T data from the mp4creator muxed file would indicate which ipod option to try.

[relaxed]

Maybe it expects the index at the beginning of the file. Try:

ffmpeg -i foo.wav -c:a aac -strict -2 -b:a 128k -ac 2 -movflags +faststart output.m4a

[Clément Bœsch]

@relaxed: both ffmpeg and avconv use faststart.

@bat999: can you try the exact following:

ffmpeg -f lavfi -i sine=d=15 -y /tmp/sine.m4a
ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no /tmp/ff.m4a
avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a

...and confirms that ff.m4a doesn't play while av.m4a plays?

(Rationale: I'm just trying to generate too very close files in order to study the differences)

[Clément Bœsch]

Oh, and can you try to use -use_editlist no with ffmpeg? It appears we are muxing one while avconv doesn't.

[bat999]

Yes, ff.m4a doesn't play and av.m4a does play.
ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no -use_editlist no /tmp/ff.m4a
avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a

@relaxed: I've already tried with faststart.

[Clément Bœsch]

Replying to bat999:

Yes, ff.m4a doesn't play and av.m4a does play.
ffmpeg -i /tmp/sine.m4a -c copy -skip_iods no -use_editlist no /tmp/ff.m4a
avconv -i /tmp/sine.m4a -c copy /tmp/av.m4a

Interesting. So, so far the only two remaining obvious differences I can notice are that the udta tag is slightly different, but more importantly the stco table is completely different:

avconv:

0000000000000000|           24     ftyp (66747970) major_brand=[M4A ] minor_version=512
0000000000000018|            8     free (66726565)
0000000000000020|         233K     mdat (6D646174)
000000000003a7cb|           5K     moov (6D6F6F76)
000000000003a7d3|          108         mvhd (6D766864) v=0 creat=0 edit=0 ts=1000 duration=15047
000000000003a83f|           24         iods (696F6473)
000000000003a857|           5K         trak (7472616B)
000000000003a85f|           92             tkhd (746B6864) v=0 creat=0 edit=0 trackID=1 duration=15047
000000000003a8bb|           5K             mdia (6D646961)
000000000003a8c3|           32                 mdhd (6D646864) v=0 creat=0 edit=0 ts=44100 duration=663548
000000000003a8e3|           45                 hdlr (68646C72) soun
000000000003a910|           5K                 minf (6D696E66)
000000000003a918|           16                     smhd (736D6864)
000000000003a928|           36                     dinf (64696E66)
000000000003a930|           28                         dref (64726566)
000000000003a94c|           5K                     stbl (7374626C)
000000000003a954|          106                         stsd (73747364) mp4a
000000000003a9be|           32                         stts (73747473)        2 entries
000000000003a9de|           28                         stsc (73747363)        1 entry
000000000003a9fa|           2K                         stsz (7374737A)      647 entries (size=0)
000000000003b42a|           2K                         stco (7374636F)      647 entries
000000000003be56|           95         udta (75647461)

ffmpeg:

0000000000000000|           24     ftyp (66747970) major_brand=[M4A ] minor_version=512
0000000000000018|            8     free (66726565)
0000000000000020|         233K     mdat (6D646174)
000000000003a7cb|           3K     moov (6D6F6F76)
000000000003a7d3|          108         mvhd (6D766864) v=0 creat=0 edit=0 ts=1000 duration=15047
000000000003a83f|           24         iods (696F6473)
000000000003a857|           2K         trak (7472616B)
000000000003a85f|           92             tkhd (746B6864) v=0 creat=0 edit=0 trackID=1 duration=15047
000000000003a8bb|           2K             mdia (6D646961)
000000000003a8c3|           32                 mdhd (6D646864) v=0 creat=0 edit=0 ts=44100 duration=663548
000000000003a8e3|           45                 hdlr (68646C72) soun
000000000003a910|           2K                 minf (6D696E66)
000000000003a918|           16                     smhd (736D6864)
000000000003a928|           36                     dinf (64696E66)
000000000003a930|           28                         dref (64726566)
000000000003a94c|           2K                     stbl (7374626C)
000000000003a954|          106                         stsd (73747364) mp4a
000000000003a9be|           32                         stts (73747473)        2 entries
000000000003a9de|           28                         stsc (73747363)        1 entry
000000000003a9fa|           2K                         stsz (7374737A)      647 entries (size=0)
000000000003b42a|           20                         stco (7374636F)        1 entry
000000000003b43e|           98         udta (75647461)

We need to investigate why our stco contains only one entry.

[Clément Bœsch]

The stco difference might be explained by fc09bf57a60d4c4a6d339b204b3282337067c06d

If you can compare before and after this commit, that would help.

[bat999]

"If you can compare before and after this commit"
I suppose that I need to compile two old versions from git.
Not sure how to do that, or which two old versions to compile.

[Clément Bœsch]

Try

git checkout fc09bf57a60d4c4a6d339b204b3282337067c06d
./configure ...
make ffmpeg

Then to go back one commit earlier with git reset --hard HEAD^, rebuild, and try again.

[bat999]

OK

Compiled "after" FFmpeg.
git checkout fc09bf57a60d4c4a6d339b204b3282337067c06d

Compiled "before" FFmpeg.
git checkout 4dcd1a3145dd93602b86a44ebc07d98ca2a30ab6

Created 15 second aac file with latest FFmpeg.
ffmpeg -f lavfi -i sine=d=15 15sine.aac

Muxed it with "after" FFmpeg.
ffmpeg -i 15sine.aac -c copy -bsf:a aac_adtstoasc after.m4a

Muxed it with "before" FFmpeg.
ffmpeg -i 15sine.aac -c copy -bsf:a aac_adtstoasc before.m4a

The "after.m4a" file doesn't play, the "before.m4a" file does play OK.
Your suggestion was right.

I also tested it with longer "before" m4a files.
It will only play files of <= 41 seconds duration, but probably that is a different issue.

[Clément Bœsch]

OK, so we indeed have a regression since 2011 in fc09bf57a60d4c4a6d339b204b3282337067c06d. Thanks for the testing. I'm marking this ticket as important.

[Michael Niedermayer]

is there anything invalid in the files generated after fc09bf57a60d4c4a6d339b204b3282337067c06d or is this a bug in the device playing the files ?

[Stefan Gehrer]

FWIW, I have written an ISOBMFF parser in the past and in my opinion the optimisation done with fc09bf57 is correct. I looked at after.m4a in a hex editor and both the stsc and stco atoms appear to be following the ISO 14496-12 spec. My guess is on a bug in the device.

[bat999]

OK

The m4a files created by FFmpeg won't play with the SanDisk Clip Sport/Jam but they will play with some/many other hardware devices.

The SanDisk Clip Sport/Jam won't play m4a files created by FFmpeg but it will play files created by some/many other software programs.

[Michael Niedermayer]

Replying to stefang:

FWIW, I have written an ISOBMFF parser in the past and in my opinion the optimisation done with fc09bf57 is correct. I looked at after.m4a in a hex editor and both the stsc and stco atoms appear to be following the ISO 14496-12 spec. My guess is on a bug in the device.

ok, adjusting title and priority

Someone should report this problem to the manufactor of the device

[bat999]

"Someone should report this problem to the manufactor of the device"

I already tried that
but got nowhere ---> ​http://forums.sandisk.com/t5/SanDisk-Clip-Jam/Clip-Jam-won-t-play-my-aac-m4a-files/td-p/350868
It will be difficult to design a "simpler" switch for FFmpeg's muxer because the Sansa decoder will probably be proprietary.
Unless they can be shamed into submitting a patch. rofl

Up to now, the best results I have is to use mp4creator v 1.6.1e-pre with Wine.
But even this isn't so good, my Sansa will only accept these files <= 30 minutes duration.
So I have to split long aac files with FFmpeg...

ffmpeg -i foo.aac -f segment -segment_time 1800 -c copy %02d_foo.aac

Then mux them with mp4creator...

for f in *_*.aac; do wine mp4creator -create="$f" ${f%.aac}.m4a;rm "$f"; done

Perhaps there is some option to use with mp4creator to solve this 30 minute limit. Beats me.

Maybe a "simpler" switch could be designed for FFmpeg to emulate mp4creator.
If anybody out there is interested in this I will be happy to test it.

The earlier Sansa players had problems with m4a files too.
They got around it by using Rockbox, but Rockbox won't work with the Clip Sport/Jam. :-(

@xubuntu:~$ wine mp4creator -h
C:\windows\system32\mp4creator.exe: option requires an argument -- h
usage: C:\windows\system32\mp4creator.exe  <options> <mp4-file>
  Options:
  -aac-old-file-format    Use old file format with 58 bit adts headers
  -aac-profile=[2|4]      Force AAC to mpeg2 or mpeg4 profile
  -allow-avi-files        Allow avi files
  -calcH263Bitrates       Calculate and add bitrate information
  -create=<input-file>    Create track from <input-file>
    input files can be of type: .263 .aac .ac3 .amr .mp3 .divx .mp4v .m4v .cmp .xvid .chap
  -encrypt[=<track-id>]   Encrypt a track, also -E
  -extract=<track-id>     Extract a track
  -delete=<track-id>      Delete a track
  -force3GPCompliance     Force making the file 3GP compliant. This disables ISMA compliance.
  -forceH263Profile=<profile> Force using H.263 Profile <profile> (default is 0)
  -forceH263Level=<level>     Force using H.263 level <level> (default is 10)
  -H263CbrTolerance=<value>   Define H.263 CBR tolerance of [value] (default: 10%)
  -hint[=<track-id>]      Create hint track, also -H
  -interleave             Use interleaved audio payload format, also -I
  -list                   List tracks in mp4 file
  -make-isma-10-compliant Insert bifs and od tracks required for some ISMA players (also -i)
  -mpeg4-video-profile=<level> Mpeg4 video profile override
  -mtu=<size>             Maximum Payload size for RTP packets in hint track
  -optimize               Optimize mp4 file layout
  -payload=<payload>      Rtp payload type 
                          (use 3119 or mpa-robust for mp3 rfc 3119 support)
  -rate=<fps>             Video frame rate, e.g. 30 or 29.97
  -qth=<height>           Set a new height for QuickTime display
  -qtw=<width>            Set a new width for QuickTime display
  -timescale=<ticks>      Time scale (ticks per second)
  -use64bits              Use for large files
  -use64bitstime          Use for 64 Bit times (not QT player compatible)
  -variable-frame-rate    Enable variable frame rate for mpeg4 video
  -verbose[=[1-5]]        Enable debug messages
  -version                Display version information