MP3 files with varying sample rate are not supported! on Win7, NewSoundSourceAPI
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Fix Released
|
High
|
Daniel Schürmann |
Bug Description
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/
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 [CachingReaderW
chronization
Warning [CachingReaderW
1 #samples: 36 bitrate: 0 samplerate: 0 flags: "0x0000"
Warning [CachingReaderW
s/kramer/
an Gorp)/01-01- Feel What We Have (feat Lodewijk Van Gorp).mp3" 32000 <> 48000
Warning [CachingReaderW
orted!
Warning [CachingReaderW
Warning [CachingReaderW
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 [CachingReaderW
d failed for" "C:/Users/
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/
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/
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."
Changed in mixxx: | |
assignee: | nobody → Uwe Klotz (uklotzde) |
Changed in mixxx: | |
milestone: | none → 2.1 |
tags: | added: soundsource |
Changed in mixxx: | |
status: | Fix Committed → Fix Released |
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?