Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange bitrates reported, e.g. 320141 instead of 320000 #328

Closed
mdeff opened this issue Nov 1, 2017 · 15 comments
Closed

Strange bitrates reported, e.g. 320141 instead of 320000 #328

mdeff opened this issue Nov 1, 2017 · 15 comments
Labels
bug

Comments

@mdeff
Copy link

@mdeff mdeff commented Nov 1, 2017

When extracting the bitrate from many mp3 files, I get strange values such as 128111, 192167, 256222, or 320141 instead of the standards 128000, 192000, 256000, and 320000.

As I can only see the standard values in mutagen/mp3/init.py, I infer these numbers have to come from the file itself. Though the bitrate is correctly reported by other tools. Take for example this audio file. With mutagen I get:

>>> f = mutagen.File('Tours_-_01_-_Enthusiast.mp3')
>>> f.info.bitrate, f.info.bitrate_mode
(320141, <BitrateMode.CBR: 1>)

With eyeD3:

>>> f = eyed3.load('Tours_-_01_-_Enthusiast.mp3')
>>> f.info.bit_rate
(False, 320)

Exiftool gives:

>>> exiftool Tours_-_01_-_Enthusiast.mp3
Audio Bitrate                   : 320 kbps
Encoder                         : LAME3.98r
Lame Method                     : CBR
Lame Bitrate                    : 255 kbps

Any idea? (What does "Lame Bitrate" mean BTW?)

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 1, 2017

uh, I guess because we don't ignore the encoder delay/padding for the calculation.

I think "lame bitrate" is the bitrate field in the lame header, which means in case of CBR, the minimum bitrate for each frame.

@lazka lazka added the bug label Nov 1, 2017
@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

Thanks for your answer. So it's a bug that will be fixed right? I.e. not an issue with the mp3 files.

In the mean time, do you know of a robust (i.e. valid for e.g. VBR mode too) way for me to correct the reported number?

@lazka lazka closed this in 008bcc9 Nov 2, 2017
@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

Thanks fro your prompt action! For the above mp3, I now get a bitrate of 320048 instead of 320141. I would still expect to get 320000 though.

Looking at 1000 such mp3s, I have the impression that the bitrate is correctly detected when the encoding mode is detected as UNKNOWN:
2017-11-02-12 55 25

But for CBR, I got values a bit off the standard bitrates.
2017-11-02-12 59 58

May that be because when CBR is detected, an exact computation is run, whereas some metadata is used to infer the bitrate if no encoding mode is detected?

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 2, 2017

yeah, I just noticed that lame includes the first frame in the byte count but not the frame count, will fix.

The files reported as unknown don't have a lame header, so we can't know the bitrate without going through the whole file, and the bitrate reported there is from the first frame.

lazka added a commit that referenced this issue Nov 2, 2017
… found. See #328

The frame count in the xing header doesn't include the first frame but the bytes
field does.
@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 2, 2017

pushed another fix

@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

Thanks! It looks much better now. The above table becomes:
2017-11-02-14 14 02

Looking at 10k mp3s, 830 are detected as CBR and 705 get a standard bitrate. The 105 others look like this:
2017-11-02-14 30 39

Any more idea? I can send links to the mp3 files if it helps.

@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

The files reported as unknown don't have a lame header, so we can't know the bitrate without going through the whole file, and the bitrate reported there is from the first frame.

That's good to know thanks. It should maybe be added to the doc.

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 2, 2017

From what I see this is due to lame having to add padding to some frames to hit the target bitrate, but that doesn't work out in all cases.

But feel free to send me a file (reiter.christoph@gmail.com)

@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

These are three faulty mp3 files (music is CC-licensed):

for tid in [640, 6669, 14298]:
    f = mutagen.File(utils.get_audio_path(AUDIO_DIR, tid))
    print(f.info.bitrate, f.info.bitrate_mode)
    print('https://files.freemusicarchive.org/' + raw_tracks.at[tid, 'track_file'])

256007 BitrateMode.CBR
https://files.freemusicarchive.org/music/WFMU/Eric_Leonardson_and_Anna_Friz/Dancing_Walls_Stir_the_Prairies/Eric_Leonardson_and_Anna_Friz_-_Waltz_of_the_Parking_Meters.mp3
192132 BitrateMode.CBR
https://files.freemusicarchive.org/music/WFMU/Flaming_Fire/Live_at_WFMUs_Free_Music_Series__Southpaw_April_2007/Flaming_Fire_-_01_-_Fire_of_Love.mp3
255719 BitrateMode.CBR
https://files.freemusicarchive.org/music/no_curator/Zornjak/S_ljubavlju/Zornjak_-_Deset.mp3

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 2, 2017

Thanks

@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 2, 2017

You're welcome! Let me know if you find something.

@lazka lazka reopened this Nov 2, 2017
@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 3, 2017

The first two files had many frames with padding while the last file had none, so the bitrate looks correct.

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 4, 2017

I don't think there is anything left to do here, so closing. Thanks for the report!

I've extended the docs a bit in 102bef7

If there are any remaining questions, please go ahead.

@lazka lazka closed this Nov 4, 2017
@mdeff

This comment has been minimized.

Copy link
Author

@mdeff mdeff commented Nov 4, 2017

Thank you for investigating and fixing the issues so quickly! :)

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Nov 5, 2017

(a new release is out)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.