[X] BPM multipled by 10 after removing comment fields?

I've just found MP3TAG, and so far, I've found it really impressive.

I've mostly been using it for batch-processing of a folder (of MP3 files), usually removing comment fields, or changing the 'genre' field.

An unexpected side-effect: I've noticed that the BPM (beats per minute) field in many MP3 files that I've processed has been multiplied by 10. An odd thing, to be sure. Confirmed by reading the file back in Tag&Rename or other programs. Also, I just tried to test to see if it could be reproduced, but it doesn't happen consistently. So something seems to be triggering it. Ideally, you'd think that the field would not be touched. But perhaps if the field is placed after others that I've removed, it is recalculated...?

Has anyone seen this?

Not very likely.
MP3tag does not look at the audio part and most certainly has no function to determine the BPMs. So this must be something else like you read other tags than you write and a modification leads to other tags to become visible.
Also, BPMs in mp4 files get leading zeros ... so perhaps that is it.

What kind of tag(version)s do you have in the files prior to treatment by mp3tag and which do you keep afterwards?
What is the difference between the files that show the behaviour and those that don't?
What does a check with mp3val reveal? AOK?

Yes, the BPM fields are already there. That's what I meant by 'multiplied by 10.' It could indeed be something related to leading zeros. But Tag&Rename reads the older tag correctly. If the old tag is 84 bpms, the new tag is set to the ridiculous "0840 bpms." (Kinda fast!)

I've just been removing the badly translated BPM fields, but the next time I notice it, I'll pay attention to any encoding info in the original source. Conceivably some quirk of the numeric encoding of the field that MP3Tag is not translating, but as mentioned, Tag&Rename has no trouble with the original field.

Not sure what mp3val is, but I'll find out. In any case, it did look to me like MP3Tag was misinterpreting the numeric value in that field.

Thanks for your reply!

Sad, that you did not answer any questions on the type of files. tag versions and results when checking the integrity of the files. Like that it is very hard to reproduce.
Can you do it?

I tried plain integers: 1
Numbers with a dot: 1.0
and numbers with comma: 1,0

None of these got changed in any way after changing any other field, not even COMMENT.
So, under these circumstance I can see no buggy behaviour.

I didn't keep track of which files. I wish now that I had. I had been trying to quickly clean up a huge number of files (hence my interest in MP3Tag), and I just went thru them and removed most of the comment tags, and anything that did not relate to the music itself (I kept artist/album/track/composer).

Even though I'm a musician, I normally don't have much use for BPM, but I just didn't think to delete the BPM fields. The differences turned up later when using "Beyond Compare"'s intelligent file compare, which does a 'diff' on the MP3 fields. I confirmed the incorrect fields afterward with Tag&Rename.

But no, unfortunately, I didn't note the tag info in the original files. I should have saved a couple of the originals.

So I'm not sure what could have triggered it, but I'm positive that the numbers were multipled by 10. I thought that someone who had worked on the MP3Tag software may recognize some place where that could occur. It is an odd and very specific bug, after all.

I'm not sure what you mean by 'type of files.' These were all MP3's, with, I believe, ID3 v3.2 tags.

In any case, I appreciate you checking. I'll be reworking more file tags later, so I will take careful notes the next time I see this.

Oh, in case it wasn't clear: This was a huge accumulation of files from all over the place, so they were originally tagged by various different rippers. I'm just guessing, but perhaps many of the BPM fields were in files from J.River's Media Center? That seems like something they would encode.

In any case, Tag&Rename had no trouble reading and decoding the files before and after, but as I mentioned, Tag&Rename did indicate the 'times 10' thing.

I found mp3val. An interesting program! I started it up on a huge number of mp3's, and it does report problems in some files, but mostly relating to 'sync' or 'garbage at end of file' (presuming ancient tag formats), or differences in the length of the MP3 data itself. I'm afraid to let it auto-correct anything before I know more about mp3val's reliability.

The 'tag' problems that it did find seemed to relate to just missing or inconsistent tags, and I didn't notice any BPM fields in those files.

The garbage at end is also reported when you hae APE tags which overwrite ID3V2 and ID3V1 tags ... so this may be one of the causes.
Do you see the multiplication when you load the files into MP3tag?
Or only if you save the files and check in other programs?

I don't know yet. I will try to find another file that exhibits the same behavior, and I'll test it more thoroughly. Or perhaps upload it. It may be a while though, as I'll have to find time to sort through a lot of files.

Thanks for keeping up with this!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.