Author Topic: A problem with in_mp3.dll and ID3v2 tags...  (Read 7783 times)

4ccur4cy

  • Posts: 3
I've got a problem trying to edit ID3v2 tags in a Mp3 with the in_mp3.dll plugin...

If I edit and save only ID3v1 tags, everything goes right...
But if I try to edit and save ID3v2 tags, I get a message saying "Can't insert ID3v2 tag! Stop playback to unlock file and try again."
In the same folder where the Mp3 is, I find a file called "xxxxxx.mp3.new" which is the same Mp3 with the new tags edited and saved.

How can I stop this and edit ID3v2 without making this new file?

Thanks in advance.
Sorry for my English.

Dotpitch

  • Posts: 2871
Re: A problem with in_mp3.dll and ID3v2 tags...
« Reply #1 on: 2 Sep '06 - 16:27 »
IIRC, ID3v1 is in the first bytes of the file, ID3v2 in the last. Adding a ID3v2 tag would make the file larger, but because XMPlay is playing it, the filelength can't be modified (the file is locked).

Unload the file from XMPlay when you edit the tags, by pressing stop two times, or by playing a different file. You could also consider using an external tagging program, like MP3Tag.

4ccur4cy

  • Posts: 3
Re: A problem with in_mp3.dll and ID3v2 tags...
« Reply #2 on: 2 Sep '06 - 16:58 »
Thank you for the tip, but I still have a couple of questions...

1) Isn't any way to edit ID3v2 tags "on-the-fly" in XMPlay?
2) Why WinAmp can edit ID3v2 tags while playing a file and XMPlay can't?

Thanks in advance.

Sebastian_Mares

  • Guest
Re: A problem with in_mp3.dll and ID3v2 tags...
« Reply #3 on: 2 Sep '06 - 19:12 »
The information is incorrect. ID3v1 is stored in the last 128 bytes of the file. Therefore, the file can be quickly opened and the ID3v1 data can be simply appended to the file. ID3v2 however is stored at the beginning of the file. Adding an ID3v2 tag requires a temporary file. The simplified process is:

Create empty file and write ID3v2 tag
Append audio track to the file containing only the ID3v2 tag
Delete source file
Rename new file to have the same name as the source file

As you can see, the source file has to be deleted and the player has to be instructed to resume playback from the new file. in_mp3 obviously can tell Winamp to do that, but it cannot tell XMPlay because it uses another "language" (probably, in_mp3 is expecting the Winamp class to fetch its window handler used for the SendMessage / PostMessage call required for stopping the playback, closing the file handle, opening the new file handle and setting the position for resuming). I guess you cannot edit tags on the fly unless Ian writes a plugin for this.
« Last Edit: 2 Sep '06 - 19:15 by Sebastian Mares »

Dotpitch

  • Posts: 2871
Re: A problem with in_mp3.dll and ID3v2 tags...
« Reply #4 on: 2 Sep '06 - 20:45 »
ID3v1 is stored in the last 128 bytes of the file. Therefore, the file can be quickly opened and the ID3v1 data can be simply appended to the file. ID3v2 however is stored at the beginning of the file.
Ah, one can learn something new every day :).

4ccur4cy

  • Posts: 3
Re: A problem with in_mp3.dll and ID3v2 tags...
« Reply #5 on: 3 Sep '06 - 09:13 »
Thank you so much for these explanations!

It's good to have a friendly community to talk with!

A lot of greetings from Rome, Italy!
(Sorry for my English...)