Re: ID3v1, anyone still using it?



Hi Weiwu

On 2014-08-10 17:50, Zhang Weiwu <zhangweiwu realss com> wrote:
On Sun, 10 Aug 2014, David King wrote:
It has been 14 years since ID3v2.4, yet a large number of players (mostly
only hardware players at this stage) still only support ID3v2.3. ;-)

I guess it is different: there is no pressing need to support ID3v2.4 -
"don't fix it if it ain't broken" attitude. But ID3v1 is broken. Even
without Chinese, it breaks at title like this:

Piano Sonata No.14 in C-sharp minor "Quasi una fantasia" - I Adagio Sostenuto
Piano Sonata No.14 in C-sharp minor "Quasi una fantasia" - II Allegretto
Piano Sonata No.14 in C-sharp minor "Quasi una fantasia" - III Presto Agitato

Note that such title has been there for a few hundred years - not a new
trend, so such titles break ID3v1 since day one.  But, ID3v2.3 is not a
broken standard.  Ain't broken, ain't fixing.

Yes, it is pretty clear that ID3v1 was "designed" for western popular music; there is only a single genre type for "Classical"! ID3v2.3 is essentially bug-free, and 2.4 is only a minor difference, although the permitted use of UTF-8 encoding is attractive.

The user, when playing back with ID3v1 player, will think EasyTag is bugged.
The fact that bottom is trimmed for user's convenience is too hard to
conceptualize, especially in this example when trimming the head is better.
If you do not write ID3v1 at all, thes user will think EasyTag doesn't do the
work. EasyTag can accept that user may feel the software didn't do the work,
but we don't accept users thinking the software is bugged or confusing. The
principle is: "If it is unable to do it, it should look like it unable to do
it, not went dead while trying".

It is possible to set a maximum length on a GtkEntry, so that the text cannot grow past the maximum allowed length for the tag format in use. This presents a problem if both ID3v1 and ID3v2 are used, as then there are 2 different field lengths. There are some other approached that might work, such as giving text past the 30 character limit a different colour, or setting a warning icon in the entry, or something else entirely.

So if we must retain ID3v1, the UI must be carefully designed to allow users
to control the behaviour that would be otherwise considered bugged, to allow
users to to fix it or prepare user for the knowledge that something is broken
- that is to make UI really messy.

Disabling ID3v1 by default is probably fine, although improving the UI to better show the limitations of the current tagging format would be useful. However, for most modern tagging formats, there are few (if any) practical limitations, so it might be a case of writing a lot of code for a legacy format which is rather broken.

From my personal perspective, I have few MP3 files in my music collection (around 5%) and all my software players support ID3v2.4, so disabling ID3v1 is an easy choice.

--
http://amigadave.com/

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]