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

[JosepMa]

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.

[Daniel Schürmann (daschuer)]

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.

[Daniel Schürmann (daschuer)]

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.

[Daniel Schürmann (daschuer)]

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

[JosepMa (josepma)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

[Uwe Klotz (uklotzde-deactivatedaccount)]

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,

[JosepMa (josepma)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

[Sean M. Pappalardo (pegasus-renegadetech)]

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?

[JosepMa (josepma)]

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

[JosepMa (josepma)]

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

[ipatrol (ipatrol6010)]

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

[ronso0 (ronso0)]

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

[Uwe Klotz (uklotzde-deactivatedaccount)]

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.

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8317