From taglib-devel Wed Jan 17 12:08:42 2007 From: "Xavier Duret" Date: Wed, 17 Jan 2007 12:08:42 +0000 To: taglib-devel Subject: Re: [PATCH] Remove trailing spaces from ID3v1 tag strings Message-Id: X-MARC-Message: https://marc.info/?l=taglib-devel&m=116903573322113 > > It seams that there is a quite popular encoder that generate ID3v1 > > frames with trailing spaces instead of using NULL terminated strings. > > This patch should be binary compatible. > > We had this discussion at least 42 times on the list by now. I hope no one here is expecting the new contributors to read the full 2 years of taglib-devel archives... The usual way to do that is to provide a FAQ but it is nowhere to be found. > Maybe taglib should get a quirks mode similar to html-renderers so the > application can decide if taglib should obey the id3 spec or do work > arounds at will. I would like to point out a significant different between ID3v1 and HTML. HTML is a standard with a specification available for free from a standardization body. As far as I know, there is no standard for ID3v1. When someone write something that does not conform to the standard, it is called a bug. If this bug has been written by a company that is a monopoly then the only way for the other companies to remain in business is to support it through "quirk modes". In the case of ID3v1, the tag was first invented in 1996 but there was no standard for it so it is no wonder that different interpretation appeared. It is only very recently that people started documenting the format properly (thereby rejecting the trailing spaces). So it is perfectly okay to be irritated by having to introduce a quirk mode for HTML but in the case of ID3v1, it is to be expected. Why would you need standards if there was no problem with proprietary formats? > IIRC The response from Scott was to fix such things inside the apps that > use Taglib. I never liked that because the quirk-fixes are reinvented in > every application. I will not debate this. It is Scott's project. He and he alone carries the burden of keeping this thing alive so if he has already made the decision then I will not discuss it. As far as I am concerned and as far as my skills in C++ go, I am going to keep on fixing all the case for which the tag parser of Firefly is better than taglib. I will then send the patches to this mailing list. The different application developers can pick them up if they want. Please also note that while fixing the quirks in C++ is quite trivial, the application developers using the C bindings will not be in such a luxury position. _______________________________________________ taglib-devel mailing list taglib-devel@kde.org https://mail.kde.org/mailman/listinfo/taglib-devel