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:

1. Use MP3Tag (or another tool) to introduce a BPM field before using Mixmeister BPM Analyzer, or
2. 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.)

_________________
Moonbase: The Problem Solver
I will not give any support for unlicensed or pirated software.

1, 2, 3. My tool is simple; garbage in, garbage out
The TBPM should be an integer but it is stored and retrieved via a string so I am reading it, casting it to a float (using 0.0f as the garbage collector) then rounding it for storage into songlist.bpm; the raw float cast is then being updated to or added to the songlist.xfade column.

4. I could go the other way if necessary; yank out the bmp (sic) part of the xfade and store it into bpm where those bpm have a 0 value.

RE standards:
I agree and also find myself not adhering to the standards via the TCOP; it is supposed to start with four numbers and I've been using (p) (c) all these years Wish the tool I used to tag would have enforced it but oh well; adopt and adapt.

However, isn't it a little hypocritical to beat the standards drum while knowingly evading them yourself?

_________________
- Steve Kunitzer
- SVS (Spacial Volunteer Support) / Forum Administrator

Gotcha! You’re so right, but we do live and work in a real world. Not everything can be perfect from the beginning, some won’t be ever … So I guess we all take whatever we feel »best« to reach our goals. And suggest improvements.

Thanks for the »knowingly«. I appreciate that.

_________________
Moonbase: The Problem Solver
I will not give any support for unlicensed or pirated software.

Adapt, adopt, and provide meaningful feedback

_________________
- Steve Kunitzer
- SVS (Spacial Volunteer Support) / Forum Administrator

Data Conditioner 1.0.0 Beta

Enjoy responsibly.

_________________
- Steve Kunitzer
- SVS (Spacial Volunteer Support) / Forum Administrator

If anyone needs to »tweak« their TBPMs before adding to SAM (i.e., double, halve, round to integer, make fractional), I posted some actions to do right that over in the MP3Tag Forums.

(Over the years I found Florian's MP3Tag to be the most flexible and adaptable tagger around—recommended.)

_________________
Moonbase: The Problem Solver
I will not give any support for unlicensed or pirated software.

Questions:
How can I tell what character set my ID3 tags are written in? Is it the same as the SAM DB?

Will using this mp3tag tool rewrite the tags in a different character set? If so, will the tags be unreadable by SAM?

_________________
erdubya
ProjectVIBE Internet Radio

I don’t want to get too much off-topic here (we’re not the MP3Tag support forum, after all), but YES. MP3Tag can be set to all spec'ed character encodings. I use it to prepare all my tags (not only MP3) BEFORE they go into the SAM database and never had any problems.

To keep things where they belong, you might want to join the thread over in the MP3Tag Forum.—Thanks.

_________________
Moonbase: The Problem Solver
I will not give any support for unlicensed or pirated software.