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 best practices (Read 5694 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ID3v2 best practices

All my serious music is FLAC files with Vorbis comments for the metadata.

However, sometimes I can only acquire audio in MP3 format, or I convert FLAC files to MP3 to get them to play outside of my computer (e.g. in my car's USB port).  So, I need to add metadata to MP3s as well from time to time.

My understanding is that APE is arguably a superior metadata format to any version of ID3, as it is a simple, clear, consistent, sane standard.  But it tragically is not as well supported, which is a killer for me, since I need, say, my car's MP3 player to understand my metadata.

So, I think that I am resigned to still using ID3.  Therefore, my overall question is what is the current best practices for ID3 tagging of MP3 files?

Aside: is search on this forum totally broken, or am I failing to understand how to use it?  I ask, because I found this relevant (but old, 2007) HA discussion using Google.  But when I copy and paste a subset of that post's title words (UTF-8 UTF-16 ID3 Tags) into HA's Search box, it finds absolutely nothing.  I mention this in case someone reading this post gets mad at me for asking a question that has been repeatedly discussed!

From what I can gather from web searches, ID3v2.3 is fairly well supported, but ID3v2.4, amazingly, still has compatibility problems.  For example, links like this and this claim that Windows still fails to support ID3v2.4.

What do you guys use?  ID3v2.3?  Any killer features in v2.4 that I would lose if I converted all my v2.4 MP3s to use v2.3 instead?

Re: ID3v2 best practices

Reply #1
I once worked on a COBOL to XML data conversion project, where I gained an appreciation for COBOL's efficiency and support for data types, even though the "everything is just text" XML was far easier to author and maintain. This helped get me away from upgrade-itis and cemented my view that there is nothing wrong with using what works, and resisting the temptation to "upgrade". It's not really an upgrade if there is a significant tradeoff being made, in this case a loss of compatibility and convenience which directly affects you. Hence, and as another example, in the U.S., where I am surrounded by British imperial measurements, I don't insist on using metric.

ID3v2.4 has no killer features. It adds internal flexibility to 2.3, but also make it way more complicated to implement. This is a common problem with technological standards hatched in ivory towers without industry or user participation, as opposed to standards which unify competing solutions already in the wild, or standards which are developed in conjunction with efficient reference implementations.

2.3 works and I am not really worried about saving a few bytes using UTF-8 instead of UTF-16. Those bytes can be more easily saved in the cover art, if any. Rearranging the info into APE tags for internal simplicity seems pointless as well, given the lack of support.

I think that although the forum's built-in search engine is case-insensitive, it is apparently doing an automatic AND (so all terms must be present in a matching post), it ignores the numbers and dashes (so UTF-8 matches posts with UTF), and it is not matching singular forms of plurals (so Tags doesn't match posts with Tag). Google's behavior differs on all three points, I believe.

Re: ID3v2 best practices

Reply #2
I just realized that the search box at the top of the page searches within the current topic if you use it while reading a topic.

Built-in search is case insensitive, and hyphenated matches work, but if you pay attention to the preview text on the search results, it won't show any context if there is no exact match for the specified string.

I'm looking for some suggestions to make the search better. We're currently using Sphinx daemon for the searches, which I just increased to performing delta indexing once every 15 minutes instead of every hour.

Re: ID3v2 best practices

Reply #3
mjb2006: thanks for your reply.  Your thoughts on sticking with ID3v2.3 are what I started leaning towards as well.  More surprisingly, yours is one of the only endorsements of COBOL that I have ever read!

Concerning this website's search engine, if I understand you correctly, my original search keywords (UTF-8 UTF-16 ID3 Tags) are equivalent to "UTF AND ID3 AND Tags" (where AND is the boolean operator).  That still should have found the post that I linked to.

That said, when I tried using just the keywords "UTF ID3" just now, it found more stuff.  The most recent and relevant for me being this 2014 post (whose consensus also seems to be ID3v2.3 would be best for me).

Re: ID3v2 best practices

Reply #4
I just realized that the search box at the top of the page searches within the current topic if you use it while reading a topic.

Built-in search is case insensitive, and hyphenated matches work, but if you pay attention to the preview text on the search results, it won't show any context if there is no exact match for the specified string.

I'm looking for some suggestions to make the search better. We're currently using Sphinx daemon for the searches, which I just increased to performing delta indexing once every 15 minutes instead of every hour.

Suppose that I go to the forum home page, so I am not looking at a particular topic at all.  If I then paste in this string "UTF-8 vs UTF-16 in ID3 Tags" (quotes not included) into the Search text field, it finds nothing at all.  So, is the search in this case not looking thru all posts, but instead just looking at the test only on that home page?

Re: ID3v2 best practices

Reply #5
Hyphens and soft-hyphens are an ignored character, so you must omit them from search queries to get any results.

Re: ID3v2 best practices

Reply #6
Hyphens and soft-hyphens are an ignored character, so you must omit them from search queries to get any results.

I would not call them "ignored characters" in that case, I would call them "poison characters"!

From the forum home page, searching for "UTF vs UTF in ID3 Tags" finds nothing, while searching for "UTF in ID3 Tags" finds 10 hits.  Oddly, my link above titled "UTF-8 vs UTF-16 in ID3 Tags?" is not one of the 10 hits.

Re: ID3v2 best practices

Reply #7
A vote for v2.3.  The original 2.3 wouldn't allow a slash in the artist name but now we have a defacto v2.3 that does.  2.4 was just silly.

Re: ID3v2 best practices

Reply #8
Try "UTF8 vs UTF16 in ID3 Tags".

Re: ID3v2 best practices

Reply #9
Try "UTF8 vs UTF16 in ID3 Tags".

In my last post, I reported that those keywords failed to find the post that I linked to.  Did something change?

OK, that worked the first time that I tried it just now (found the post I linked to).

BUT when I tried it again a second time, it failed...

In between those 2 searches, I tried searching for "UTF-8 vs UTF-16 in ID3 Tags?".  That still failed, but it seems to have poisoned the subsequent search (which obviously should not happen, since there should be no memory between searches).

Re: ID3v2 best practices

Reply #10
You must leave off the quotes, or else it will search for that exact phrase. Which will fail, due to the hyphens being excluded on the index.


Re: ID3v2 best practices

Reply #12
The original 2.3 wouldn't allow a slash in the artist name

Yeah ... that was a dirty deed done dirt cheap.

On the other hand and unlike those guys whom I think you referred to, (they always had it), Guns'N Roses are back to having a Slash again and I see nobody complaining about it. ;D
Listen to the music, not the media it's on.
União e reconstrução

Re: ID3v2 best practices

Reply #13
You must leave off the quotes, or else it will search for that exact phrase. Which will fail, due to the hyphens being excluded on the index.

All my searches have always left off the quote marks.  I only used them in my posts in order to demark the key words.  Perhaps I should have done some different formatting, like put the key words in fixed width font?


Re: ID3v2 best practices

Reply #15
OK, I gather that the HydrogenAudio consensus seems to be that ID3 v2.3 is the way to go.  I will be converting my mp3s this weekend using mp3tag.  Thanks for the feedback, guys.

Re: ID3v2 best practices

Reply #16
A vote for v2.3.  The original 2.3 wouldn't allow a slash in the artist name but now we have a defacto v2.3 that does.  2.4 was just silly.

The only reason I don't use 2.4 to tag audio is because of Windows Explorer and Windows Media Player.

The benefit to 2.4 is UTF-8. If Microsoft supported it, all ID3 tags I create would use it just for that reason alone. But it doesn't, so I'm stuck with 2.3 and UTF-16.

 

Re: ID3v2 best practices

Reply #17
Quote
ID3v2.4 has no killer features. It adds internal flexibility to 2.3, but also make it way more complicated to implement. ......
2.3 works and I am not really worried about saving a few bytes using UTF-8 instead of UTF-16.
Respectfully disagree.

ID3v24 isn't significantly harder than ID3v23, the problem is more than many applications have never completed full ID3v23 support.

What ID3v24 does have is support for multi values fields separated by null seperator, which is useful. Also if your player incorrectly views an UTF8 field as ISO-8859-1 it maybe readable, but not a UTF16 field.

Really the choice depends on what software you are going to use the files with, and what that software supports - if it supports ID3v24 I would use that..