Analyze is messing up Bitrate

[Mel Grubb]

I have a lot of new files that I've recently added. All of these were self-ripped, and 320kbps. Windows reports this when looking at the file details as well, but when I run Analyze on them, some (not all) of them change to ridiculous numbers like 18kbps, meaning that I would never pick that file when playing out, even though it's really 320kbps.

I would edit the files back to normal one at a time, but that's not an editable field. I can reload track metadata from the file, which resets the bitrate, but throws out all of the analyzed information like BPM and Key. Why is Analyze even touching the Bitrate field. That's not information that requires analysis to figure out. It's encoded directly into the file.

[kek001 (kek001)]

Yes it does, same problem here.

[Daniel Schürmann (daschuer)]

On which OS are you?
Win 10 64 bit?
Which decoder are you using?

Can you attach a free license file to this bug report that is effected?
Or mail it to me at daschuer mixxx org

[Mel Grubb (melgrubb)]

Sorry. Hadn't checked in in a while. I'm on Windows 10, and these are MP3 files. Do you still need an example file? I can track one down, but it sounds like this has already been confirmed, so maybe you don't need it anymore.

[Uwe Klotz (uklotzde-deactivatedaccount)]

No, I'm not able to reproduce this issue. The avg. bitrate reported by the MP3 decoder for all my MP3 files is reasonably correct and doesn't change when analyzing files. This applies to both VBR and CBR encoded files.

I have 2 M4A files with a wrong bitrate, but this is caused by invalid metadata and does not change when analyzing.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Some metadata properties like duration, number of channels, sample rate, and bitrate are just informal and might be wrong or inaccurate. These properties are replaced with the actual values reported by the decoder when opening/decoding the audio stream.

[kek001 (kek001)]

i am using win 7,32. and no idea what is the logic, because
allmost every tracks from album. but then leaves one without messing. mpeg 1 Layer III
lame 3.99r,joint stereo 320,

[Uwe Klotz (uklotzde-deactivatedaccount)]

Please provide an example file that shows unexpected behaviour (download link via PM). Otherwise we are not able to verify if this is caused by a bug in Mixxx, in the MP3 decoder, or simply a non-standard file.

[Mel Grubb (melgrubb)]

I tried to send an example file, but the attachment was rejected. Where can I send it directly?

[Uwe Klotz (uklotzde-deactivatedaccount)]

Upload it somewhere and send a link via private message. Attaching the file here is not appropriate if publishing is not allowed due to license restrictions.

[Uwe Klotz (uklotzde-deactivatedaccount)]

I can confirm this issue on Windows for the example file. The avg. bitrate calculated from the MP3 headers decoded by libmad is 3 kbps instead of 320 kpbs. On Linux everything works as expected and the bitrate is correctly reported as 320 kbps.

This is very strange, because libmad is used both for decoding on Linux and Windows. Do we have an issue with our Windows toolchain and build environment??

[Daniel Schürmann (daschuer)]

We have the re-occurring bug that we cannot select library rows on windows. https://bugs.launchpad.net/mixxx/+bug/1751482
That may also build system related. Which build did you use for testing on Windows?

[Uwe Klotz (uklotzde-deactivatedaccount)]

Tested with the AppVeyor artefacts from this PR: https://github.com/mixxxdj/mixxx/pull/1877

[Uwe Klotz (uklotzde-deactivatedaccount)]

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

Please test the resulting AppVeyor artefact after the CI build finished.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Unfortunately all AppVeyor Windows builds are currently timing out. I was able to verify the fix with an AppVeyor build from an earlier build.

[Uwe Klotz (uklotzde-deactivatedaccount)]

A 64-bit Windows executable is available for testing:
https://ci.appveyor.com/project/mixxxdj/mixxx/builds/20338643/job/mqje099ysujmp57f/artifacts

[Swiftb0y (swiftb0y)]

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