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