failed to play mp4 files with 960 and 1024 samples per block

[mixxxbot]

Reported by: JosepMaJAZ Date: 2015-11-24T20:26:02Z Status: Fix Released Importance: Undecided Launchpad Issue: lp1519472 Tags: mp4 Attachments: ffprobe_show_frames.zip

---

OS: Windows 10 Mixxx version : 2.0 RC ( 5642 and older) as well as 2.1 alpha (5457), 64 and 32bit. No 3rd party (windows) codecs installed.

I have detected a problem playing some m4a files on Windows. I haven't been able to test if this affects the playback under linux, but maybe we can assume this affects only the mediafoundationsoundsource. The files plays fine with other software like foobar2000 and even windows media player.

The files load ok and there's no problem in analyzing or using them, but when playing them, they sound as if a CD player was playing a dirty cd and silenced small amounts of audio. It is not skipping (i.e the playback duration is not affected) The problem affects the decoding, not the playback itself. I.e. If I increase the playback speed, these fragments of silence happen more often. I have recorded the audio output with Audacity, and the exact bug is as if at some intervals, it reduced the volume to minimum, and did a fast fadein (around 400 samples or so, i can't be precise)

I have been able to determine that there is a problem with the MP4 container, as I took one of the files that were playing bad, and with the help of ffmpeg, and using the "copy" codec (i.e. just repack the stream in a new container), the problem was gone.

Comparing it to other files, it might be a problem with the stts MP4 atom, but that's from a simple binary inspection, so I could be wrong.

http://psycle.free.fr/josepma/mixxxm4abug/DHT%20-%20True%20love%20%28Makina%20Mix%29%20-%20bad.m4a <- the bad one
http://psycle.free.fr/josepma/mixxxm4abug/DHT%20-%20True%20love%20%28Makina%20Mix%29%20-%20good.m4a <- same file, with the fixed container using ffmpeg

Song is copyrighted, but is old (from the 90's). I couldn't make a 30 second sample, because then i get a new container and the bug "fixes" itself. I will delete the files when the bug gets fixed.

[mixxxbot]

Commented by: daschuer Date: 2015-11-24T22:16:08Z

---

I have tested you file with Linux and I can't play it at all. This is the log output:

Warning [CachingReaderWorker 1]: Unable to decode tracks with non-fixed sample durations:  "file:///home/daniel/Arbeitsfläche/DHT - True love (Makina Mix) - bad.m4a" 
Warning [CachingReaderWorker 1]: Failed to open SoundSource 
Warning [CachingReaderWorker 1]: Failed to open file: "/home/daniel/Arbeitsfläche/DHT - True love (Makina Mix) - bad.m4a" 
Debug [CachingReaderWorker 1]: "[Channel1]" CachingReaderWorker::loadTrack() load failed for" "/home/daniel/Arbeitsfläche/DHT - True love (Makina Mix) - bad.m4a" ", file invalid, unlocked reader lock 
Debug [Main]: Failed to load track "/home/daniel/Arbeitsfläche/DHT - True love (Makina Mix) - bad.m4a" "The file '/home/daniel/Arbeitsfläche/DHT - True love (Makina Mix) - bad.m4a' could not be loaded." 

I can play it with gstreamer based players.

[mixxxbot]

Commented by: daschuer Date: 2015-11-24T22:22:30Z

---

Comment from Source.

// Read fixed sample duration.  If the sample duration is not
// fixed (that is, if the number of frames per sample block varies
// through the file), the call returns MP4_INVALID_DURATION. We
// can't currently handle these.

This explains also the issues on Windows. Instead of playing the file as stream, Mixxx probably seeks to the positions as if the sample duration is fixed. Since this is not the case you hear clicks and silence.

[mixxxbot]

Commented by: daschuer Date: 2015-11-24T22:23:57Z

---

What percentage of files in you collection is effected? Can we consider the file as broken?

[mixxxbot]

Commented by: JosepMaJAZ Date: 2015-11-24T23:17:52Z

---

There aren't many. In fact the first time I found one of those I thought that I had a bad rip. And indeed, we can assume that the data is incorrect (even if it is only the container). It was just strange that it only failed in Mixxx.

I will fix the rest that I find with ffmpeg, although I don't have an easy way to locate them.

Maybe the windows version should do as the linux version and not play it.

[mixxxbot]

Commented by: uklotzde Date: 2015-11-26T00:19:11Z

---

Other decoders might simply make the assumption that a block always contains 1024 samples (this what Mixxx did up to version 2.0):

http://spectralhole.blogspot.de/2010/09/aac-bistream-flaws-part-2-aac-960-zero.html

The file should have either 960 or 1024 samples per block, but not a mixture of both or even different numbers.

[mixxxbot]

Commented by: uklotzde Date: 2015-11-26T00:34:18Z Attachments: ffprobe_show_frames.zip

---

ffprobe -show_frames reports 10895 "frames" (or "blocks"), each containing 1024 samples:

nb_samples=1024

Something else must be wrong with the file that FAAD2 fails to determine the number of samples per block in MP4GetTrackFixedSampleDuration().

[mixxxbot]

Commented by: uklotzde Date: 2015-11-26T00:40:32Z

---

You might also use ffprobe to identify other faulty files by their properties like the encoder:

Input #⁠0, mov,mp4,m4a,3gp,3g2,mj2, from 'Music/Corrupt Tracks/DHT - True love (Makina Mix) - bad.m4a': Metadata: major_brand : M4A minor_version : 512 compatible_brands: isomiso2 genre : Rave artist : DHT replaygain_track_gain: -4.56 dB replaygain_track_peak: 0.961389 title : True love (Makina Mix) encoder : Lavf56.23.106 Duration: 00:04:12.98, start: 0.000000, bitrate: 127 kb/s Stream #⁠0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) Metadata: handler_name : SoundHandler Side data: replaygain: track gain - -4.560000, track peak - 0.000022, album gain - unknown, album peak - unknown,

[mixxxbot]

Commented by: JosepMaJAZ Date: 2015-11-26T00:46:24Z

---

I've already said that the problem is in the container, not in the bitstream. There are probably some incorrect atoms in the mp4 header that don't reflect the real data. We need to find if this canbe detected and ignored, or make it fail, rather than play it bad.

[mixxxbot]

Commented by: uklotzde Date: 2015-11-26T00:50:45Z

---

The Windows decoder for AAC uses Microsoft Media Foundation and is completely different from the Linux (FAAD2) and OSX (CoreAudio) decoders.

[mixxxbot]

Commented by: Pegasus-RPG Date: 2015-11-26T01:11:44Z

---

Yes, Uwe, he's aware of that. The question is 1) can we make such files play okay on Windows? If not, should we play them however we can or not at all?

[mixxxbot]

Commented by: JosepMaJAZ Date: 2015-11-26T09:54:21Z

---

I am searching the files that present this problem (i have around 800 files in m4a format which i have to check) and so far, it looks like it was a problem with a specific version of ffmpeg. All the files i've found with this problem have that long and strange stts atom, and are created with that version of the avformat, Lavf56.23.106. Files created with a newer version don't show this problem.

So i guess it was a bug that existed there, and that sort of simplifies the job of finding the files that have this problem.

On the Mixxx side, i still think that looking at that atom for validity could help on detecting these files. I also found this commit on the videolan project that might be related to this bug:

http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=7c82aac1267eccf02ec7306d5aa0fb76e8b873a4

[mixxxbot]

Commented by: JosepMaJAZ Date: 2015-11-26T11:27:40Z

---

Update: looking only for that version of the avformat library was not enough. I have many files with that version that work well. But the files that fail do have that long and strange stts atom. Now I only need a way to scan for this (or i'll have to resort to visual inpection with an hex editor...)

[mixxxbot]

Commented by: ipatrol6010 Date: 2016-03-09T08:21:06Z

---

I'm not sure if this is the same bug, or perhaps a related one, but I've had issues where songs will cut out between a third and a half of the way through. I think it's the same issue from https://www.mixxx.org/forums/viewtopic.php?f=3&t=7850

[mixxxbot]

Commented by: ronso0 Date: 2016-09-25T15:19:06Z

---

I can confirm this bug for rev5936 compiled on linux with faad=1

Debug [CachingReaderWorker 2]: SoundSourceProvider "Nero FAAD2" created a SoundSource for file "file:///mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" of type "m4a" 
Warning [CachingReaderWorker 2]: Unable to decode tracks with non-fixed sample durations:  "file:///mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" 
Warning [CachingReaderWorker 2]: Failed to open AudioSource for file "file:///mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" with provider "Nero FAAD2" 
Warning [CachingReaderWorker 2]: No SoundSourceProvider for file "file:///mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" 
Warning [CachingReaderWorker 2]: Failed to open AudioSource for file "file:///mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" 
Warning [CachingReaderWorker 2]: Failed to open file: "/mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" 
Debug [CachingReaderWorker 2]: "[Channel2]" CachingReaderWorker::loadTrack() load failed for" "/mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" ", file invalid, unlocked reader lock 
Debug [Main]: Failed to load track "/mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a" "The file '/mnt/M_OOLI/audio/00__mu__iN/00__neo/fail_cut.m4a' could not be loaded." 

[mixxxbot]

Commented by: uklotzde Date: 2016-10-10T16:39:55Z

---

http://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_Application-Bulletin_AAC-Transport-Formats.pdf

Footnote 13: "The usual frame length for AAC-LC is 1024 samples, but a 960 sample version is used for radio broadcasting, and 480 or 512 sample versions are used for the low-delay codecs AAC-LD and AAC-ELD."

Proposal: Instead of rejecting to decode the file we could log a warning and use the default frame length of 1024 instead. That might work for the majority of files.

[mixxxbot]

Commented by: uklotzde Date: 2016-10-12T11:55:13Z

---

https://github.com/mixxxdj/mixxx/pull/1027

[mixxxbot]

Issue closed with status Fix Released.