MP3 files with varying sample rate are not supported! on Win7, NewSoundSourceAPI

[mixxxbot]

Reported by: default-kramer
Date: 2015-04-22T01:52:16Z
Status: Fix Released
Importance: High
Launchpad Issue: lp1446931
Tags: soundsource

---

On the NewSoundSourceAPI branch, I get this message on some of my tracks: "MP3 files with varying sample rate are not supported!" These tracks play in the current master branch, and all the other media players I have installed.

Here is the some debug output. Most of the examples mismatch 44100 vs 48000, but this one is 32000 vs 48000.

Debug [Main]: m_sTracks.count() = 1
Debug [Thread (pooled)]: Reading tags from file "C:/Users/kramer/Music/Amazon Mu
sic/Alankara, Jazzy D/Feel What We Have (feat Lodewijk Van Gorp)/01-01- Feel Wha
t We Have (feat Lodewijk Van Gorp).mp3" of type "mp3"
Warning [CachingReaderWorker 1]: Recoverable MP3 header decoding error: lost syn
chronization
Warning [CachingReaderWorker 1]: MP3 frame header | layer: 0 mode: 0 #channels:
1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Warning [CachingReaderWorker 1]: Differing sample rate in some headers: "C:/User
s/kramer/Music/Amazon Music/Alankara, Jazzy D/Feel What We Have (feat Lodewijk V
an Gorp)/01-01- Feel What We Have (feat Lodewijk Van Gorp).mp3" 32000 <> 48000
Warning [CachingReaderWorker 1]: MP3 files with varying sample rate are not supp
orted!
Warning [CachingReaderWorker 1]: Failed to open SoundSource
Warning [CachingReaderWorker 1]: Failed to open file: "C:/Users/kramer/Music/Ama
zon Music/Alankara, Jazzy D/Feel What We Have (feat Lodewijk Van Gorp)/01-01- Fe
el What We Have (feat Lodewijk Van Gorp).mp3"
Debug [CachingReaderWorker 1]: "[Channel1]" CachingReaderWorker::loadTrack() loa
d failed for" "C:/Users/kramer/Music/Amazon Music/Alankara, Jazzy D/Feel What We
 Have (feat Lodewijk Van Gorp)/01-01- Feel What We Have (feat Lodewijk Van Gorp)
.mp3" ", file invalid, unlocked reader lock
Debug [Main]: Failed to load track "C:/Users/kramer/Music/Amazon Music/Alankara,
 Jazzy D/Feel What We Have (feat Lodewijk Van Gorp)/01-01- Feel What We Have (fe
at Lodewijk Van Gorp).mp3" "The file 'C:/Users/kramer/Music/Amazon Music/Alankar
a, Jazzy D/Feel What We Have (feat Lodewijk Van Gorp)/01-01- Feel What We Have (
feat Lodewijk Van Gorp).mp3' could not be loaded."

[mixxxbot]

Commented by: daschuer
Date: 2015-04-22T09:23:28Z

---

This it the side effect from fixing Bug #⁠1444478

It is most likely that the files are corrupt. You may verify it with
checkmp3 -v
and may fix it later with the same tool.
But please keep th original files for further testing.

I am curious to see the results here.

The issue is somehow hard to solve.
Mixxx calculates a seek table of mp3 frame header. These header have no CRC and are only verified by a plausibility check.
If the stream has corrupt data that are still a valid header Mixxx tries to process it.
If it tries later to decode these frames with the faulty header data, the frame is rejected in the best case because of follow up errors and will produce a notable click and offsets between beat-grid and sound . If it is not rejected, you will hear just noise, or even worth crash Mixxx.
Both cases are not desirable to putting this to an audience.

So it is correct to reject them entirely in Mixxx in the first place.

On the other hand the average user will not understand. why a entertained track will not play.

Any idea how to solve this?
What will be the best approach?

[mixxxbot]

Commented by: uklotzde
Date: 2015-04-23T06:06:11Z

---

I see different options based on different assumptions.

1st assumption (status quo): Files should/must have a consistent sampling rate in each frame

• Reject the file as is done now

  2nd assumption (Mixxx <= 1.12.0): Sampling rates in subsequent MP3 frame headers might be wrong (why? encoders?)

  • Only read the first valid sampling rate from an MP3 frame header
  • Ignore all sampling rates from subsequent MP3 frame headers
  • Log warnings about unexpected/varying sampling rates

3rd assumption: Sampling rates in MP3 frame headers may vary from frame to frame

• Apply resampling internally
• New parameter: A target sampling rate preferrably provided by Mixxx to avoid resampling multiple times

[mixxxbot]

Commented by: uklotzde
Date: 2015-04-23T06:12:23Z

---

Do your files play correctly in Mixxx 1.11/1.12? Then my 2nd assumption applies to your files.

But which assumption applies to the majority of the files out there?? I have not yet found a concise description of the MP3 format that clearly states if varying sampling rates are allowed in a single file.

[mixxxbot]

Commented by: uklotzde
Date: 2015-04-23T09:37:08Z

---

I checked the mpg123 sources:

• The 3rd assumption is correct, i.e. internal resampling is required
• The 2nd assumption (Mixxx 1.11/1.12)is wrong and produces distorted audio
• The 1st assumption (Mixxx master) at least prevents us from playing tracks that we are currently not able to play

Looks like it's time to replace the MP3 decoder, because libmad is just too limited.

[mixxxbot]

Commented by: daschuer
Date: 2015-04-23T10:09:14Z

---

Hi Uwe,

my view is slightly different:

• The current 1.11 and 1.12 implementation is a bug and needs a fix urgently.
• A file with changing sample rate can be assumed as faulty file.

The mp3 format supports changing sample rates, but what will be the way to have that in a file.
I can only think of a recorded radio stream, switching the station. That is not the kind of files we need to play in MIxxx.
So rejecting them in the fist place is OK

If we now assume, that a changing sample rate file is in fact a corrupt file. It is wrong to play the corrupt frame using a re-sampling algorithm. In the best case the frame is rejected by the decoder anyway, but it is not guaranteed, because the frame crc seams to be usually not used.

I have thought about the solution for my file, which starts with a corrupt frame. What about counting the frames of each sample rate and play the file with the most common settings. Skipp all frames that do not match these settings.
This is probably similar to the 1.11 state where the first frame is luckily a valid one.

And Yes, we will experience clicks because of that, but remember, the file is corrupt.

How do you like the idea?

[mixxxbot]

Commented by: daschuer
Date: 2015-04-23T10:19:56Z

---

Of cause switching to mpg123 is also a valid solution. I just wonder which new issues will be introduced by that.
How is the seek accuracy and the cpu performance?
How will the faulty files sound and seek, compared to a hack inside Mixxx?

[mixxxbot]

Commented by: uklotzde
Date: 2015-04-23T10:50:09Z

---

Using the most common sampling rate found in all frame headers is definitely an option.

I don't think that it is possible or at least desirable to skip individual frames, because the decoder must be fed with a consecutive sequence of frames. Skipping arbitrary frames in the stream would also complicate seeking!

[mixxxbot]

Commented by: daschuer
Date: 2015-04-23T11:44:34Z

---

I am curious to see if the decoder is able to decode the frames anyway.

If yes, we will receive garbage, if not we will have no transport and finally a seek error. right?

If we assume that the decoder finally skips the frames, we may want to reflect it in the seek table.
But it is probably not worth the work, because those files are rare and we are not sure what bad will happen.

So lets try the "most common" setting solution. Should I give it a try or are you "almost started"? Than I would be happy to test it.

[mixxxbot]

Commented by: uklotzde
Date: 2015-04-23T13:36:02Z

---

No, I haven't started yet. Since everything is available on master now, you can give it a try if you like ;)

[mixxxbot]

Commented by: daschuer
Date: 2015-04-23T21:48:20Z

---

A possible fix is here:
#564

[mixxxbot]

Commented by: daschuer
Date: 2015-04-25T08:53:36Z

---

@kramer: The solution works for my files on Linux. I am curious to hear if this solves your issues on Win as well.
The fix is included in th latest builds at:
We have now builds http://downloads.mixxx.org/builds/1.12/release/

[mixxxbot]

Commented by: default-kramer
Date: 2015-04-25T18:06:27Z

---

Thanks Daniel, with the fix all my problematic files play correctly now.

I've noticed a new issue, I think, where you can't rewind very far past the beginning of a track, and rewinding as far as you can causes playback to get stuck at at a position with negative elapsed time. I'll do some more investigation later and create a new bug since it seems unrelated to this one.

[mixxxbot]

Issue closed with status Fix Released.