Be aware. There are some caveats to all this:
1. The ID3v2.3 specs clearly state that TBPM should be an integer field.
Now, as many good DJs will tell you, for a »perfect mix« one should have an accuracy of about .05 BPM. Mixmeister BPM Analyzer and many other tools actually try that, by storing something like »63.5« or »086.01« in this (text) field. Other applications store the same values as an integer, assuming 1/100 fraction, i.e. »6350« or »08601«.
So there should probably be a means of converting between the two. (Personally, I strongly opt for [and actually use] the xxx.xx format, and for changing the spec.)
2. Since TBPM is a text type tag, it can have a character encoding identifier. The spec clearly states that numbers have to be stored in ISO-8859-1 encoding (i.e., ASCII, for this case).
Sadly enough, some BPM detection tools store this field with a different encoding! Like using UTF-16 for ID3v2.3, or UTF-8 for ID3v2.4.
3. Mixmeister BPM Analyzer is notorious in rewriting ID3v2.3 tags as UTF-16, even if they have been read as ISO-8859-1!
This apparently occurs
only when the BPM tag
is not already there (i.e., Mixmeister has to rewrite the tags). When the BPM tag already exists, its only
updated (i.e., the text encoding of the rest of the tags unchanged).
Since it is not advisable to have different character encodings in one’s collection (and not many players or broadcasting software understands UTF-16 anyway), there seem to be
two solutions to this problem:
- Use MP3Tag (or another tool) to introduce a BPM field before using Mixmeister BPM Analyzer, or
- use MP3Tag (or another tool) to re-save the tags in the correct encoding (i.e., ISO-8859-1) after using Mixmeister BPM Analyzer.
EDIT: Only solution (2) seems feasible. I did some more diagnosis and found that Mixmeister always writes TBPM in UTF-16, so with solution (1) you would end up with a file having mixed character encoding! That doesn’t make too much sense.I did intentionally not mention
UTF-8 here, since it is strictly
not allowed in ID3v2.3 tags, and not many software correctly interprets ID3v2.4 tags (where it
is a valid character encoding).
4. SAM (at least version 4.2.2) is notorious in messing up tags if »Save Tag« is used from the Song Info. For example, it appears to ALWAYS overwrite the TBPM tag with a »0«!
I strongly feel some tagging stuff in SAM should be changed, for example USING the TBPM field for BPM instead of XFADE &bmp=xxx.xx! (And I actually believe some programmer made a typo here—why is it not »&bpm«?)
The sad thing is that SAM's BPM auto-detection library ain't that bad, only we can't USE it since it doesn't save in TBPM (or read it), while many other tools broadcasters and DJs use do.
Well, enough said about the caveats I'm currently fighting with … I strongly feel we should urge the software guys to USE and IMPLEMENT standards instead of always trying to somehow circumvent their programming errors … sigh.
(There was a similar discussion over in the MusicIP forums, on how to integrate BPM into their database and today I found the same thing going on here. Life could be much easier if anyone would just correctly implement what's THERE.)