# Using v3.32d with BPM tag (TXXX BPM)
**URL:** https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245
**Category:** No Bugs
**Created:** [November 29, 2025, 4:59pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245 "2025-11-29T16:59:12Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 29, 2025, 4:59pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/1 "2025-11-29T16:59:12Z")
Hello @Florian, I tried Mp3tag Development Build Status v3.32d
I thought it was great what you changed about ID3v2 tags
CHG: writing ID3v2 tags preserves the original ID3v2 frames that were not modified.
CHG: writing ID3v2 tags allows for writing multiple non-standard WXXX frames with the same description.
I ran tests with my 35 BSI Info Editor (Simian) tags. I saved (Ctrl+S) all 35 tags without modifying them using Mp3tag (I didn't use Tools Ctrl+1, "Make selected tracks BSI compatible.cmd" for my Comments and TXXX BPM tags).
I used Notepad++ to quickly review the results for my 35 tags.
I noticed that my tags retain the same data, except for my TXXXBPM tag.
The reading should be: TXXX BPM101
There's a bug; I'm losing the TXXX data and getting the following data: BPM101APIC
See my two screenshots
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 29, 2025, 5:32pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/2 "2025-11-29T17:32:34Z")
Hello @Florian, as you know, in earlier versions of Mp3tag,
the result of my TXXXBPM tag was changing to TBPM.
I placed two images:
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [November 29, 2025, 6:11pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/3 "2025-11-29T18:11:28Z")
It looks to me a lot like the behaviour discussed in depth and detail in this thread:
> [@Mp3tag BPM Tag not recognized with VLC Media Player](https://community.mp3tag.de/t/mp3tag-bpm-tag-not-recognized-with-vlc-media-player/66897):
>
> Mp3tag BPM Tag not recognized with VLC Media Player I did some tests with the BPM tag (TBPM) of Mp3tag, I noticed that it is not recognized in the VLC Media Play…
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 29, 2025, 6:55pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/4 "2025-11-29T18:55:01Z")
Hello @ohrenkino, I remember our discussions about this very well…
Following our discussions, I asked my Simian teacher in Canada if there was a program that could read the Simian BPM tag, and he said yes.
We have a Natural Music program, so we use it to manage Simian programming, including tags from BSI Info Editor (Simian). The TXXX BPM tag (Simian) is used by radio studios that broadcast shows, especially for music categorized as fast (Dance Music) or slow (Ballads)…
You saw my two images, proof included. I still maintain that it's a bug…
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [November 30, 2025, 6:36am UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/5 "2025-11-30T06:36:08Z")
> [@Sergius](#):
>
> There's a bug; I'm losing the TXXX data and getting the following data: BPM101APIC
Don't you see your BPM value in a program that used to show it?
Changing a userdefined (TXXX) field with the name of BPM to a standard BPM-field is the well known Mp3tag-behaviour and was explained to you before.
> [@Mp3tag BPM Tag not recognized with VLC Media Player](https://community.mp3tag.de/t/mp3tag-bpm-tag-not-recognized-with-vlc-media-player/66897/38):
>
> I prefer to currently not add any configuration option to allow writing ID3v2 frames TXXX:BPM instead of TBPM. I believe that many valid explanations were already given and I'd prefer everyone who is missing support for this standard frame to instead ask the developers or company behind the respective tool to add support for TBPM. If this is not an option, there is plenty compatible software out there (also recommended in this topic) which might make life a little easier.
APIC has nothing to do with your bpm-value. It belongs to the embedded cover-image.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 30, 2025, 7:09pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/6 "2025-11-30T19:09:09Z")
Hello @poster,
I showed you the bug with two images. I definitely have a bug, and I think you don't understand the problem at all. I'll explain further:
> [@poster](#):
>
> APIC has nothing to do with your bpm-value. It belongs to the embedded cover-image.
Okay, if "APIC" is the embedded cover image, it's the Mp3tag V3.32d program that's placing this data in my TXXXBPM. I don't know why the program is doing this; it's never done this before. The only one who could explain it to me is @Florian, he's the programmer…
I ran some more tests. I reinstalled Mp3tag V3.32 on my computer, and with this version, I no longer have this bug with the "APIC" data…
This proves beyond a doubt that it's the Mp3tag V3.32d program that's placing the "APIC" data in my TXXXBPM.
poster, what you sent me is true for Mp3tag V3.32 and earlier versions:
If my tag is TXXXBPM 101, I make a backup without changing my BPM, and it will automatically revert to TBPM 101. I don't have any problems with that. That's how it's always been before.
In my Mp3tag programming, I have a Tools menu (CTRL+1) that allows me to reprogram my TXXXBPM101.
poster, for Mp3tag version V3.32d, I believe what Florian wrote is:
CHG: writing ID3v2 tags preserves the original ID3v2 frames that were not modified.
Correct me if I'm wrong, but it's the same as the Kid3 program. I've already done a lot of testing with that program. If I modify one tag, Kid3 only saves the modified tag, without modifying the other tags. It works perfectly with my 35 tags in BSI Info Editor (Simian).
Now, if Mp3tag seems to be doing the same thing, it's causing a bug... if I don't modify the BPM tag, the Mp3tag V3.32d program still modifies my BPM tag by adding the data "APIC". That doesn't make sense?
I'm asking Florian: could it be that the data "APIC" is being added to my TXXXBPM tag by mistake? This tag is the last tag in my Mp3tag Tag Panel. I don't have any problems with the other tags...
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [November 30, 2025, 7:23pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/7 "2025-11-30T19:23:23Z")
Do oyu see that behaviour after you treated the file with the tool?
I just saved a file with 3.32d with a modified BPM value and it looks like this:
no APIC following TBPM.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 30, 2025, 7:53pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/8 "2025-11-30T19:53:29Z")
Hello @ohrenkino,
this has nothing to do with the TBPM tag… You're mistaken…
The new version, Mp3tag 3.32d, is different; it's not the same thing anymore…
My tag is called TXXXBPM. With this new version, Mp3tag 3.32d, if I don't change my TXXXBPM tag, Mp3tag 3.32d won't change it, according to what Florian wrote…
> [@Mp3tag Development Build Status](https://community.mp3tag.de/t/mp3tag-development-build-status/455/1):
>
> CHG: writing ID3v2 tags preserves the original ID3v2 frames that were not modified.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [November 30, 2025, 7:59pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/9 "2025-11-30T19:59:30Z")
> [@Sergius](#):
>
> could it be that the data "APIC" is being added to my TXXXBPM tag by mistake?
It's very unlikely and nothing like that is happening in my tests. One question: do you see the `APIC` as part of your BPM field in Mp3tag or is this revealed in another program?
What I see from your screenshots above, is that the `TXXX BPM` frame has no trailing `NUL` after the actual BPM value `101`. Mp3tag usually writes a trailing `NUL` (or `0x00`) after the textual content of a frame, because it's the most compatible (although not required by the standard).
It seems like the `TXXX BPM` frame that was carried over, doesn't have this additional trailing `0x00` character and whatever you use to display the data is disturbed by it.
If you like, you can send me an example file before the change in Mp3tag and another one after the change, I'll have a closer look.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 30, 2025, 8:36pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/10 "2025-11-30T20:36:33Z")
Hello @Florian, it's true that I don't see the "APIC" data appearing in Mp3tag or BSI Info Editor (Simian). I don't have enough knowledge on this subject to know if the "APIC" data could cause problems when programming BPM (Natural Music) with BSI Simian…
I've been thinking about this:
> [@poster](#):
>
> APIC has nothing to do with your bpm value. It belongs to the embedded cover image.
My last tag in Mp3tag Tag Panel is: TXXXBPM, and immediately after it I have the image, and between the BPM tag and the image I have the "APIC" data.
Do you think it's possible that the "APIC" data appears there because of this?
I will send you the audio file with the tag TXXXBPM101, which you can test with Mp3tag V3.32d
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [November 30, 2025, 8:39pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/11 "2025-11-30T20:39:49Z")
> [@Sergius](#):
>
> Hello @Florian, it's true that I don't see the "APIC" data appearing in Mp3tag or BSI Info Editor (Simian).
Where do you see it then, except for Notepad++?
> [@Sergius](#):
>
> My last tag in Mp3tag Tag Panel is: TXXXBPM, and immediately after it I have the image, and between the BPM tag and the image I have the "APIC" data.
>
> Do you think it's possible that the "APIC" data appears there because of this?
I think it's because this is the first modified tag that gets added after the unmodified frames are carried over.
If you, instead of the image, add another field that wasn't there before, e.g., `COMPOSER`, you'll see the frame identifier of the added frame, e.g., `TCOM`.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [November 30, 2025, 9:12pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/12 "2025-11-30T21:12:32Z")
Hello @Florian,
I took another audio file and tested it with Mp3tag32d. I still have the "APIC" data, but the TXXX data is visible. I might have had a problem with my first test file. I'll send you my other audio file with TXXXBPM101.
I had only looked in the Mp3tag and BSI Info Editor (Simian) programs. I did a final test with Reaper, and I don't see the "APIC" data.
TXXX:BPM: 101
Thank you for your answer to my question.
Here is a more detailed image from the Notepad++ test with Mp3tag32d.
You will see my last two tags: Tempo, TXXXBPM101APIC followed by the data: image /jpeg
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 1, 2025, 8:14am UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/13 "2025-12-01T08:14:53Z")
Thank you for the example file. I analysed its contents, and it is essentially like I described above:
The `TXXX BPM` frame has no trailing `0x00` after the textual content (i.e., the bpm number), which is perfectly fine, as the content size of 8 bytes is reflected in the frame header:
- 1 byte: Text Encoding
- 3 bytes: Description `BPM`
- 1 byte: Delimiter `0x00`
- 3 bytes Value: `101`
This frame is written differently from the other frames in that file, which suggests that a different tool was used to write the `TXXX BPM` frame (possible, but not certain).
The `TXXX Tempo` frame for example, does have a trailing `0x00` after the textual content, which again is reflected by the total frame size of 14 bytes (`0x0E`):
- 1 byte: Text Encoding
- 5 bytes: Description `Tempo`
- 1 byte: Delimiter `0x00`
- 6 bytes Value: `Medium`
- 1 byte: Trailing `0x00`
* * *
As a result, if another frame is added after the `TXXX BPM` frame in this file, the new frame identifier (e.g., `APIC` or `TCOM`) would appear directly after the BPM value. But because each frame contains its frame size in the frame header, any software can easily identify the frame boundaries.
I hope this clarifies what you observed. Please let me know if you still think this is a bug in Mp3tag.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [December 1, 2025, 5:33pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/14 "2025-12-01T17:33:30Z")
A big thank you, @Florian, for your tests; I understand the writing processes much better now…
> [@Florian](#):
>
> This frame is written differently from the other frames in that file, which suggests that a different tool was used to write the `TXXX BPM` frame (possible, but not certain).
Rest assured, no different tool was used to write the TXXX BPM image; it was done using only Mp3tag v3.32d.
I'm going to show you all the steps for my BSI Info Editor (Simian) audio file with Mp3tag v3.32 and Mp3tag v3.32d.
With Mp3tag v3.32, the results of my BSI Info Editor (Simian) audio file:
Mp3tag v3.32: A save (CTRL+S)
Result:
Here are two images:
My TXXXBPM101 tag is transformed into the TBPM101 tag.
My second-to-last tempo tag, the APIC data, and the image/JPEG.
Mp3tag v3.32: I'm using a Tools menu (CTRL+1)
In my folder: C:\BSI-Mp3tag
id3.exe
Create selected tracks BSI compatible.cmd (For tag COMMENT and tag TXXXBPM)
Result:
Here are two images:
The tag TBPM 101 is changed to tag TXXXBPM101.
My second-to-last Tempo tag, the APIC data, and the image/jpeg data remain unchanged!
Now, Mp3tag v3.32d shows the results of my audio file from BSI Info Editor (Simian).
Mp3tag v3.32d: A backup (CTRL+S)
Here is one image:
With Mp3tag v3.32d, I notice that the APIC data is entered with the following data:
BPM (NUL)101APIC,
However, I recognize that the APIC data does not appear in the following programs: Mp3tag, BSI Info Editor (Simian), and Reaper. Based on your tests, I think there shouldn't be a problem for those who want to use the TXXXBPM tag with the Natural Music program for BSI Simian.
Florian, I have the following question: why does Mp3tag v3.32 place the APIC data this way (NUL)APIC(NUL) and differently in Mp3tag v3.32d?
I will send you the following programs privately:
To perform the same tests as me with a Tools application, if you have the time, using Mp3tag v3.32 and Mp3tag v3.32d:
Mp3tag Tag Panel v5.0 (Win 10) VIA BSI Info Editor-Simian (Configuration\_June 2025).ini
id3.exe
Make selected tracks BSI compatible.cmd
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 1, 2025, 7:05pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/15 "2025-12-01T19:05:17Z")
> [@Florian](#):
>
> This frame is written differently from the other frames in that file, which suggests that a different tool was used to write the `TXXX BPM` frame (possible, but not certain).
> [@Sergius](#):
>
> Rest assured, no different tool was used to write the TXXX BPM image; it was done using only Mp3tag v3.32d.
You sent me an unmodified original file, which wasn't written by Mp3tag v3.32d. The structure of the `TXXX BPM` _frame_ (not _image_) indicates that it was written by another tool than the one that wrote the other frames in the file.
> [@Sergius](#):
>
> Florian, I have the following question: why does Mp3tag v3.32 place the APIC data this way (NUL)APIC(NUL) and differently in Mp3tag v3.32d?
Your question shows that my previous explanation wasn't clear enough. Could you please read it again and try to understand it? The reason is that in earlier versions, Mp3tag rewrote the entire tag and all of its frames (including converting `TXXX BPM` frames to `TBPM` frames). Now, however, unmodified fields and their corresponding frames are carried over unchanged and reused for the new tag.
> [@Florian](#):
>
> Please let me know if you still think this is a bug in Mp3tag.
> [@Sergius](#):
>
> However, I recognize that the APIC data does not appear in the following programs: Mp3tag, BSI Info Editor (Simian), and Reaper.
I take this as a "No" and move this to #Bug Reports > No Bugs
* * *
With regard to the tools you sent me, I don't believe I need to use them to arrive at the conclusions I have already outlined in my posts in this topic.
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [December 1, 2025, 8:45pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/16 "2025-12-01T20:45:21Z")
Hello @Florian,
I misunderstood your question. The audio file I sent you wasn't modified with Mp3tag v3.32d; that's what I meant. I meant that the APIC data appearing in TXXXBPM101APIC(NUL) was modified using only Mp3tag v3.32d, without using any tools.
The audio file you received... I've made a new, more precise cut: TXXXBPM101(NUL)(NUL)...
> [@Florian](#):
>
> Now, however, unmodified fields and their corresponding frames are carried over unchanged and reused for the new tag.
Based on what you just wrote to me, and what you wrote during the Mp3tag v3.32d update:
The logic is that I should have the same data written with Mp3tag v3.32d.
My existing data:
TXXX(NUL)…BPM(NUL)101(NUL) (NUL) NUL)…
It seems to me that my data should be written this way with Mp3tag v3.32d:
… BPM(NUL)101(NUL)APIC(NUL)(SOH)…
To answer your question about whether there's a bug with Mp3tag v3.32d, I don't think so!
Regarding the question I raised in my last message:
Florian, you're an excellent programmer; I don't have half your knowledge, I'm stuck in my reasoning:
There's a missing piece of data (NULL) between 101 and APIC. However, I do have this data, which exists in TXXXBPM101(NULL) (NULL)... in the audio file you received...
Does the programs detect the APIC data? The answer is no.
From what I can see, there shouldn't be a problem with the TXXXBPM using version Mp3tagv3.32d. For someone wanting to program TXXXBPM101APIC with Natural Music, I think it will work...
Unfortunately, I can't test the TXXXBPM. I haven't received any training on the Natural Music program for the BSI Simian Tag BPM, and my program wasn't programmed for the Sections. BPM, otherwise I would have done a test…
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 2, 2025, 8:46am UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/17 "2025-12-02T08:46:22Z")
> [@Sergius](#):
>
> The logic is that I should have the same data written with Mp3tag v3.32d.
> My existing data:
> TXXX(NUL)…BPM(NUL)101(NUL) (NUL) NUL)…
>
> It seems to me that my data should be written this way with Mp3tag v3.32d:
> … BPM(NUL)101(NUL)APIC(NUL)(SOH)…
At this point, I need to assume that you're trying to understand what's going on with the internal structure of the ID3v2 tag, but unfortunately don't understand the internals — while at the same time trying to reason on the basis of those very internals.
As I wrote above:
> [@Florian](#):
>
> The `TXXX BPM` frame has no trailing `0x00` after the textual content (i.e., the bpm number), which is perfectly fine, as the content size of 8 bytes is reflected in the frame header:
>
> 
>
> - 1 byte: Text Encoding
> - 3 bytes: Description `BPM`
> - 1 byte: Delimiter `0x00`
> - 3 bytes Value: `101`
This means that you don't have
`TXXX(NUL)…BPM(NUL)101(NUL) (NUL) NUL)…`
but your `TXXX BMP frame actually only is
`TXXX(NUL)…BPM(NUL)101`
and any additional `(NUL)` you're seeing doesn't belong to the frame you're inspecting. You really need to take the frame size into account.
> [@Sergius](#):
>
> There's a missing piece of data (NULL) between 101 and APIC. However, I do have this data, which exists in TXXXBPM101(NULL) (NULL)... in the audio file you received...
As I explained above, it's not missing but the tool you used to add the BPM information decided to encode it differently (without trailing `(NUL)`) than the other frames in the file you sent — which is not a problem (also explained above).
---
### Author:  [@Sergius](https://community.mp3tag.de/u/Sergius)
#### Post date: [December 2, 2025, 3:44pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/18 "2025-12-02T15:44:20Z")
> [@Florian](#):
>
> The `TXXX BPM` frame has no trailing `0x00` after the textual content (i.e., the bpm number), which is perfectly fine, as the content size of 8 bytes is reflected in the frame header:
>
> 
>
> - 1 byte: Text Encoding
> - 3 bytes: Description `BPM`
> - 1 byte: Delimiter `0x00`
> - 3 bytes Value: `101`
> [@Florian](#):
>
> and any additional `(NUL)` you're seeing doesn't belong to the frame you're inspecting. You really need to take the frame size into account.
> [@Florian](#):
>
> As I explained above, it's not missing but the tool you used to add the BPM information decided to encode it differently (without trailing `(NUL)`) than the other frames in the file you sent — which is not a problem (also explained above).
Thank you @Florian for your additional explanations, which help me better understand your initial explanations.
If I understand your explanations correctly, the data frame where the example 101 BPM data is stored is read by programs like Mp3tag, BSI Info Editor (Simian), and Reaper. They read this data only within the frame assigned to it and don't take into account subsequent data like (NULL) or APIC, which isn't part of that frame.
This proves beyond a doubt that there's no bug.
The tool I use to add BPM information also chooses to encode it differently. The encoding is correct because it respects the BPM, frame assigned , which isn't a bug either.
Congratulations on your excellent work, and thank you again for your excellent explanations.
Have a great day! 😊 👍
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [January 1, 2026, 3:44pm UTC](https://community.mp3tag.de/t/using-v3-32d-with-bpm-tag-txxx-bpm/70245/19 "2026-01-01T15:44:41Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.