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.

Poll

ID3v1?

You can pry my v1 from my cold dead Zip drive!
[ 0 ] (0%)
Lyrics extension!
[ 0 ] (0%)
Meh, rid of it since long.
[ 9 ] (69.2%)
Who cares? Set all my applications to ignore it.
[ 2 ] (15.4%)
Still need it for in-car use and ...
[ 2 ] (15.4%)
Don't remove! I did and <please specify> went completely wrong
[ 0 ] (0%)

Total Members Voted: 13

Topic: Any particular "lesser known" reason to keep ID3v1 tags?  (Read 3147 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Any particular "lesser known" reason to keep ID3v1 tags?

I have my MP3s tagged with ID3v2.3 and ID3v1 - and It seems I finally have no devices that depend upon ID3v1. Maybe.
Some applications show like COMMENT ID3v1 fields and the like, and that is sometimes annoying but also makes me a bit cautious.
So:
Is there anything valuable that I don't know about, that should keep me from bulk nuking ID3v1 off my drive?

(Like ancient stuff that might affect playback ... ? Chances are it has already been destroyed.)
And if so:
What should I search for before deleting, and in what tagging app?

I was thinking of letting Mp3tag do the job, before or after the year-end backup.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #1 –
Probably Ok with modern devices. You can test a few tracks before doing them all. Easy to add/remove them with fb2k.
Years ago I had a cheap Laser player that needed v1.0 or 1.1 .

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #2 –
What's the big problem with keeping them (I'm a belt-and-braces type)?
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #3 –
I don't keep them.  I remove and/or convert iD3V1 tags found.  I only use IDV2.3.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #4 –
Until the very early 2000's, I maintained both. I had issues with some tagging software truncating the ID3v2 tags to match the ID3v1 tags.  I even had one hardware player ignore ID3v2 tags if ID3v1 tags were present.  I just found it to be a headache keeping ID3v1 tags.

Most of the hardware players I've had that displayed tags were car stereos.  For at least the last 20 years, they've displayed ID3v2 tags.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #5 –
7. I just don't care.

Older files have it, I don't touch them. I love my files intact.

New ones don't have it.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #6 –
Quote from: fooball on
What's the big problem with keeping them (I'm a belt-and-braces type)?
I had to get rid of them many years ago, because I had hardware players that would prefer v1 and show me the truncated tags, even when v2 was present. The solution was to remove v1, and I haven't used it since.

Re: Any particular "lesser known" reason to keep ID3v1 tags?

Reply #7 –
The combination of buggy applications might make a case for one or the other - and here it is against end tags, even the more sane APEv2.
Especially when one of those is a fairly common one: Looking at you, ffmpeg.

I have a bunch of MP3 files which "aren't terminated properly" - it seems some applications keep converting to the end of the source file, and then stopping, leaving the last MPEG frame incomplete? Anyway, those show up as "truncated" when using zealous MP3 validation software.

And then ffmpeg keeps on reading. Into the tags section, if there are any such at the end.
Sure one may - sometimes - appreciate that an application that tries to salvage out as much audio as possible from corrupted files, but for standard playback you would rather have it mute than spit noise at you.

Anyway, until ffmpeg fixes this, then its audio hash functionality is broken. The foo_audiomd5 component uses ffmpeg, and if the file has this kind of truncation at the end and you change end-tags - then the "audio checksum" will come out wrong.
It seems one avoids it by never changing end-tags. Which in turn, is most easy to do if you don't use end-tags at all.

(I was once musing about dropping ID3 altogether and going for APEv2. Won't happen. ID3v2.3 has its shortcomings, but at least it is supported. And since I intended using foo_audiomd5 for fingerprinting lossies ... writing that to APEv2 on those truncated files, will immediately invalidate it.)