MP3 channel and decoding fix#568
Conversation
The decoding functions do NOT return the actual error code!! Instead the error code must be read from mad_stream if the decoding functions returned != 0. This caused some really ugly sounds at the beginning of some MP3 files, because frames were not skipped as suppossed to be.
There was a problem hiding this comment.
I think this deserves some more comments. I an not sure where, I am still trying to understand. Please correct me:
"Here we are, if we have decoded a mono sample. This can be either intended or a faulty frame"
There was a problem hiding this comment.
"And If we decode a mono file"
|
LGTM. Thank you. Will it simplify the code, if SoundSourceMp3 predicts to be always be stereo? |
Slightly more code, but hopefully easier to understand.
|
Restriction to stereo: It would eliminate the maximum channel calculation and 1 of 3 cases when reading sample data. I don't think that it's worth to alter the code again without any real issues, now that we have a general approach with lots of sanity checks. If you think about an optimized mono path for audio processing in the future (I often switch the master output to mono) then this artificial restriction could even become counterproductive. |
|
Thank you for the fix. There are strange errors at Travis: I have just build an test this version without such errors. So it is hopefully a server issue. |
|
I'm currently seeing test failures on 1.12 for EngineBufferE2ETest.ScratchTest. But on master everything is fine :) |
Fixes: https://bugs.launchpad.net/mixxx/+bug/1448224
SoundSourceMp3