Mp3tag writes BPM with decimals in m4a files which is non-standard. This doesn't happen in version 3.23, the BPM is rounded up in this version. In newer versions it doesn't check if it has decimals, which can be a problem if, like me, you have a script to double or halve the BPM. This script will place a couple of 00, for example a value of 60 will become 120.00 when doubled. But this 120.00 is non standard in m4a files. So I cannot use newer versions than mp3tag 3.23 if I want to avoid this issue.
MP3tag does not determine BPMs - they must come from another application.
Which MP3tag version have you tried?
I just tried 3.35-beta.1 and that just displays the plain value. No padding, no decimals.
Also:
what does this script look like? Is ts an MP3tag action?
I can confirm the difference here regarding M4A files. I tested this using an older version (3.21). In that version, manually entered decimal numbers were rounded down. In current versions, the entered decimal number is saved exactly as entered. For MP3, FLAC, and WAV files, decimal numbers were saved - rather than rounded down - even in version 3.21.
1 Like
It does, try to write 121.85 in the bpm field in version 3.23: it will be rounded down to 121. Try to write 121.85 in latest version and it will write 121.85 which is non-standard and will create problems with a lot of apps that don't understand this format. Just try that.
In fact it would be better if it rounded the number to the nearest one, not the way it was done in version 3.23: if the BPM is, let's say, 121.52 it should be rounded to 122; if it is 121.45 it should be rounded to 121.
I’ll look into that, thanks for reporting.
1 Like
I doubt that it would make a difference.
The following makes me wonder about the relevance:
BPM stands for "beats per minute" - so if you you round down or up you have a difference of 1.5 beats in a 3 minute piece.
Bpms with decimals either occur in files where a human drummer enforced the rhythm - and such a person probably never plays like a metronome which means that no-one will notice the slightly increased or decreased intervals between 2 beats.
And BPM is, AFAIK, an average value anyway with little relevance in pieces that have widely varying parts in respect to rhythm (e.g. Band on the run by the Wings, Music by John Miles, Bohemian Rhapsody by Queen etc.)
As you say that you double or halve the bpms: MP3tag only allows integer arithmatic. So $mul(%bpm%,2) or $div(%bpm%,2) would lead to integers anyway. That is why I asked which script you use.
Which is relevant if your mixing 2 tracks for a long time in electronic music. Long before you skip a whole beat you will notice the desynchronization. Since I am a DJ I know for sure.
In reality it won't make much of a difference since the DJ programs will analyze the BPMs to the cent anyway, but if you're gonna do it why not do it right? I want the BPMs in tags for reference when searching for songs. I have a script that doubles or halves the BMPs (which is important when BPM analysers get it wrong) and leaves the resulting value with two decimal digits which perfect when doubling flac or mp3 since that's the way BPMs analysers give their results, with two decimal digits. So if I double a mp3 of 80.02 it will be 160.04. I like the precision. I really don't need it since the DJ program ends up doing it but I like the precision.
Format value “BPM”: $if($grtr($strchr(%BPM%,'.'),0),$add($mul($left(%BPM%,$sub($strchr(%BPM%,'.'),1)),100),$left($mid(%BPM%,$add($strchr(%BPM%,'.'),1),2)00,2)),$mul(%BPM%,100))
Format value “BPM”: $mul(%BPM%,2)
Format value “BPM”: $ifgreater(%BPM%,0,$left(%BPM%,$sub($len(%BPM%),2)).$right(%BPM%,2),0.00)
And there's another problem. If I already have a CD compressed at, let's say, 128kbps, mp3, and then I get a m4a newer version with more quality I want to be able to copy the tags. So I select the already properly tagged mp3 songs with their BPMs stored with two decimal digits (the standard) and copy, let's say, 10 songs tags onto the 10 new non-tagged songs of the new album in m4a. The new versions of Mp3tag will write the BPMs with two decimal digits in the m4a files and no program apart from Mp3tag will be able to read those values. And this is something I do a lot, so it is annoying and that's why I still use version 3.23 that does it right (except the proper rounding). Ok?