Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ID3v2 Tag Saving Is Destructive (Read 13979 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ID3v2 Tag Saving Is Destructive

I'm finding that saving ID3v2 tags using F2k 0.9 is destructive in some cases.

My ripping and tagging toolchain is as follows:

EAC->FLAC->MP3(convert in F2k)->Tag&Rename->ReplayGain(in F2k)

I don't worry too much about tags until after the MP3 encoding step.  After that I tag to a combination of ID3v2 and ID3v1 (for backwards compatibility) in Tag&Rename.  ID3 embedded album art jpgs are added in most cases.  Next I use F2k to scan for replaygain and add replaygain tags.  When F2k saves tags back to the files, some of the ID3v2 data is lost.  Specifically, the ID3v2 artist, tracknumber and album art data is missing. 

Looking at pre/post copies in a binary compare confirms that the data has been changed. 

So, my question is, is there a way to have F2k retain the existing ID3v2 tag data when saving replaygain data?  Is there any reason it is saving back the entire tagset and not just the new replaygain tags? 

Thanks.

ID3v2 Tag Saving Is Destructive

Reply #1 –
I've never run into that problem, actually. I don't use ID3v1, but i have applied ReplayGain to MP3s that had v1+v2 on them (because i downloaded them from somewhere), and it didn't affect the tags at all.
~

ID3v2 Tag Saving Is Destructive

Reply #2 –
Good to know it's not happening to you, but it has been 100% reproducible in my tests.  Happy to provide sample before and after files if that is helpful.

ID3v2 Tag Saving Is Destructive

Reply #3 –
Well i don't know if i'll be able to help you, since i'm not really an expert, but that would be cool if you could, 'cause i want to try. :x


edit:
Maybe this is a problem with the versions of ID3v2 that foobar and T&R use? I know foobar uses 2.4, but i stopped using T&R when i found foobar a year or two ago, so i don't know what they use (or if their implementation is compliant).
~

ID3v2 Tag Saving Is Destructive

Reply #4 –
T&Rs docs claim ID3v2.4 compliance.  I don't see a setting to have it preferentially write 2.4 instead of 2.3 tags.  I've had no problems with iPod or Slimserver software consuming these tags.

When reopening one of the files written to by F2k, T&R shows the artist and track number correctly in the ID3v1 view (album art missing), but not in the ID3v2 view.  Looks like F2k is only saving back the one set of tags instead of both. 

Unless there is interest on the part of others in changing the overall tag saving behavior, I'm not too sure that would be the best resolution.  To my mind, I wonder why F2k saves back all of the tags when adding RG tags, instead of just adding the delta RG data.

ID3v2 Tag Saving Is Destructive

Reply #5 –
Just to be clear: The tags are missing in both foobar and T&R, right? Or is it just T&R?
~

ID3v2 Tag Saving Is Destructive

Reply #6 –
F2k's property window shows a value for artist and tracknumber.  The "other info" pane shows "tagtype = id3v2|id3v1".  But, it seems to be getting the artist and tracknumber data from the v1 tags.  Looking directly at the file data in a binary comparison tool, it shows that the second copy of this data in the tag header is missing after the F2k update.  So the data looks OK in the F2k "view", but is truncated for some other uses, such as the case when only the v2 tags are used.

ID3v2 Tag Saving Is Destructive

Reply #7 –
foobar2000 0.9 writes ID3v2.4 tags where text is encoded as UTF-8 and unsynchronization is applied to all binary frames (like APIC for cover art).

Current Tag&Rename treats UTF-8 encoded ID3v2.4 tags as ISO-8859-1 and ignores unsynced APIC frames. Seems like Tag&Rename only supports a part of the ID3v2.4 standard and you should ask their support staff on how to proceed.

ID3v2 Tag Saving Is Destructive

Reply #8 –
I'm not sure what you mean by "unsynchronization".  Does that mean that this data is discarded?  If so, why?

Tag&Rename claims full Unicode support since the v3.2 release.  Have you seen evidence that this is not correct in this version? 

Would you be at all interested in seeing sample files showing the before and after states?
 

ID3v2 Tag Saving Is Destructive

Reply #9 –
i dont even use 0.9 yet because of all these little inconsitencies, but i have heard that it only saves id3v2 tags when necessary. so if all of your data fits into the confines of an id3v1 tag, foobar just uses that.

im curious to know, if fb2k decides that id3v2.4 is needed, does it keep the id3 tag too? i have some hardware that only reads id3v1 tags and it would be sad if they all disapeared.

also, maybe you can change how this all works in some preferences?

ID3v2 Tag Saving Is Destructive

Reply #10 –
Quote
i dont even use 0.9 yet because of all these little inconsitencies, but i have heard that it only saves id3v2 tags when necessary. so if all of your data fits into the confines of an id3v1 tag, foobar just uses that.
[a href="index.php?act=findpost&pid=377971"][{POST_SNAPBACK}][/a]


IIRC, foobar uses whatever tag type is already there.  If you have ID3v2, you get ID3v2.4.  If you had APEv2, you get that.

ID3v2 Tag Saving Is Destructive

Reply #11 –
I've ran into another problem - I have a file that's tagged both id3v1 and id3v2, but id3v1 is truncated for one or another reason. foobar reads id3v1 even though more complete set of data is available on id3v2 and is ignored by foobar.

And, some data written by other mp3 managing software is lost during foobar's mp3 tag rewriting, since foobar either doesn't know about them or doesn't take care of them while deciding what version of id3 tag to use. Plus it somehow mangles my tags the oddest way that my traktor evaluation copy loses quite a bunch of info written by it to mp3 files (FBPM, cue points, etc are either rounded to integer or discarded)

And, for some reason foobar adds a square symbol that's visible to latest version of iTunes (v6.0.4.2 for the time of writing) but it's not visible by foobar. Maybe line ending characters?

Winamp v2.95 isn't detecting any id3 tag at all after retagging with foobar2k v0.9
- Eugene 'HMage' Bujak

ID3v2 Tag Saving Is Destructive

Reply #12 –
Quote
I'm not sure what you mean by "unsynchronization".  Does that mean that this data is discarded?  If so, why?[a href="index.php?act=findpost&pid=377967"][{POST_SNAPBACK}][/a]

I'm not an expert but i think he's talking about the dealie that's applied to ID3v2 frames to make old players ignore the tags.
~

ID3v2 Tag Saving Is Destructive

Reply #13 –
[deleted]

ID3v2 Tag Saving Is Destructive

Reply #14 –
[deleted]

ID3v2 Tag Saving Is Destructive

Reply #15 –
[deleted]

ID3v2 Tag Saving Is Destructive

Reply #16 –
Quote
Winamp v2.95 is outdated when it comes to ID3v2 and does not correctly support ID3, and fails to read ID3v2.4 tags all together.  This is updated and fixed in the latest versions of Winamp.


Allright. Just wanted to do a quick check for old software compatability. As a sidenote, I know quite a bunch of people who stay away from winamp 5 because it's quite cumbersome compared to v2.


Quote
I'm going to look into thi to see if I can find any technical reasons why you are having problems with Native Instruments software.  What version of Traktor Studio are you having these problems with?


Traktor 2.

As I've checked, it seems that v0.9 is writing id3 tags differently than v0.8. I don't lose exact BPM now. But I still can lose the artist and track name if they're longer than id3v1 permits for some reason.

Exact actions to replicate the behaviour:
1. we have a file that doesn't have any id3 tags at all.
2. write with traktor DJ studio tags to the file, use long title and artist ("a very long string test for foobar's id3 tag handling", for example)
3. reload tags from file in foobar.
4. change first letter in both title and artist to yield possible checks for modification.
5. write tags to file in foobar.
6. read tags from file in traktor.
7. the artist and title strings will be cropped down to "b very long long string test for fo".


Quote
The square symbol seems to be a known issue, but I've yet to see this on iTunes here (but only tested with v6.0.4.3/PPC, at least with files with both ID3v1 and ID3v2.4 tags)!  iTunes correctly identifies these files as ID3v2.4.  There are no squares in the playlist, at least.  I do not use iTunes very much, so maybe I am not looking in the right place.


I tried to reproduce the issue again:
1. a file with no id3 tags.
2. tag the file with itunes, add artist: "Test artist", album: "Test album", track: "test track". Probably iTunes will add sound check data right after adding the test song to the library and write it as an id3 tag.
3. Read the tags with foobar,
4. add date: "2006".
5. write tags with foobar back to file.
6. start playing back the file. The squares will be on title, album and track.

The issue causes losing the tracks sometimes from the library, and adding duplicates of the same song because, for iTunes, their titles don't match.


Quote
I also do not think that data should be lost, but when the tag is written in ID3v2.4, the software may not be reading the tag correctly.  This is actually very common ID3 issues, and part of the reason why fb2k was not supporting ID3 out of the box in older releases.


I understand that. But I think it's still can be quite a hassle that unknowingly, by using foobar, an user will suddenly 'loose' the tags on half of their mp3 library after a year, for example.

[a href="index.php?act=findpost&pid=378040"][{POST_SNAPBACK}][/a]
- Eugene 'HMage' Bujak

ID3v2 Tag Saving Is Destructive

Reply #17 –
Here's a followup to the original thread topic. 

My issue was in trying to use a tagging toolchain that included both Tag&Rename v3.2 (for basic tags + album art) and Foobar2000 v0.9 for replaygain tagging. 

Each of these programs appears to me to the the among the best at performing it's individual task.  They just don't work together very well since upgrading to F2k v0.9.  As of this release, when Foobar writes the replaygain tags, it creates problems with the album art, artist and tracknumber information. 

The software packages that I need to be able to properly consume the resulting tag sets are SlimServer and the iPod firmware. 

The reason that this occurs appears to be complex.  There seem to be compatibility issues between ID3 tag version (v1, v2.3, v2.4) specs, as well as the individual software implementations of the specs. 

The result is simply that the tags generated by one program aren't guaranteed to be interoperable with other programs.  The developer of each program seems to genuinely think they've done the right thing, but the result is still the same. 

Just in case anyone else has run into this issue, I am sharing a workaround method that appears to solve my problem. 

====================================================

Method to use Tag&Rename v3.2 for tagging in concert with Foobar2000 v0.9 for ReplayGain without data loss.

0. Foobar - strip all tags (right click -> Tagging -> Remove tags from file(s))
1. Tag&Rename - tag everthing _except_ album art (use ID3v2 only mode)
2. Foobar - add ReplayGain tags (don't apply to audio data)
3. Tag&Rename - add _only_ album art (use ID3v2 only mode)

Problem:

When Foobar2000 v0.9 writes back tag data after a ReplayGain scanning run, it does so in a way that interferes with the tagging pattern used by Tag&Rename v3.2.  This can result in the loss of Artist, Tracknumber and AlbumArt data.  I don't fully understand the incompatibility, but have devised the a workaround.  Using the above method, I've found it possible to successfully save MP3 files that contain full ID3v2.4 tags, embedded album art and album/track replaygain adjustment tags.
====================================================

ID3v2 Tag Saving Is Destructive

Reply #18 –
that sounds like a real pain in the ass.

i love foobar and was really looking forward to upgrading, but if it is actually destroying tags created by other programs (dj software - djdecks to be exact), then i just cant do it.

are flac tags a problem too?

ID3v2 Tag Saving Is Destructive

Reply #19 –
I found another way of causing tag destruction when I try to apply ID3v2.4 tags in both iTunes and 0.9. It seems to be dependent on the album art in this case.

1. Stripped all the tags via Foobar. Set ID3v2 only.
        When I checked the files in iTunes, all the tags remained except for album art.
2. Tagged files in Foobar.
3. Checked iTunes: Squares were at the end of Artist, Album and track fields and the "total tracks" field was gone.
4. Selected 'Get Info' in iTunes, went to 'Info' tab. Square dissapeared.
5. Readded 'total tracks'. Checked foobar, tag appears. Everything fine.
6. Reapplyed Album Art via iTunes.
7. 'Reload info from file(s)' in Foobar. All tags are gone in Foobar, all tags remain in iTunes.

I was able to get Foobar to read (or copy) all the iTunes tags once but I haven't been able to recreate it yet.

Edit: This even happens when I try to specify APEv2 only. It will wipe the album art when I add tags and when I re-add the art in iTunes it will clear all the Foobar tags.

Edit: I started using Florian's MP3Tag and it works perfectly. I guess I won't be using the masstagger anymore. Thanks.

ID3v2 Tag Saving Is Destructive

Reply #20 –
Quote
are flac tags a problem too?[a href="index.php?act=findpost&pid=378314"][{POST_SNAPBACK}][/a]
No, FLAC never suffered from the same problems as MP3 did with ID3, because FLAC actually has a tag format defined in its specification, and it doesn't have the problem of multiple incompatible versions of a pseudo-standard tag format (see ID3v2.x).

ID3v2 Tag Saving Is Destructive

Reply #21 –
Quote
that sounds like a real pain in the ass.

are flac tags a problem too?


It is kinda painful.  It means jumping back and forth between the different programs, refreshing tag data each time.  But it gets me the results I want.  I make good backups, so I should only have to do it once.  And just about a thousand more CDs to go...

FLAC uses it's own tag format.  That seems to work w/o issue.