Hi Weiwu On 2014-08-10 09:48, Zhang Weiwu <zhangweiwu realss com> wrote:
I started a new topic 'cos it seems seperate. By writing both ID3v1 and ID3v2 we have these questions: - What if ID3v2 contains more characters than allowed in ID3v1? Is the ID3v1 version trimmed?
Yes, ID3v1 fields are truncated to 30 characters.
- When ID3v2 contains non-ASCII, what is written in ID3v1? EasyTag defaults to ISO-8859-1 but AFAIK this is unspecified, and ISO-8859-1 is a western convention. Most audio file you can find in China contains China's local encoding in ID3v1 and in Japan it is the same.
EasyTAG writes ISO-8859-1 into ID3v1 by default, as this is the convention. As ID3v1 is a de facto standard (not even an informal standard like ID3v2), and was created by westerners, this convention stems only from the origins of the format, although it is widely followed in the west. Standardising on a universal encoding was one of the driving ideas behind ID3v2.
- What to do if EasyTag reads a file with both ID3v1 and ID3v2, and the data there are inconsistant? This happens a lot in case of encoding mismatch.
In this case, the ID3v2 tag takes precedence. Upon writing, the ID3v1 tag is overwritten with the tag data shown in the UI, which would in general be the same as the ID3v2 tag, but may be truncated or have encoding differences.
These problems are gone if we do not write ID3v1 tags, and indeed I configured my EasyTag so. But whether or not we should default to this, depends on the following: - What would players do if they see both ID3v1 and ID3v2? Do all of them consistantly prefer using ID3V2?
This is, unfortunately, very difficult to find out.
- 16 years has passed since ID3V2. Are there players that still only support ID3V1? I do not think there are any, but, maybe there a practical reason to use ID3v1 - for example some home music player may have LCDs of exactly 60 characters space on them, and since they rely on ID3 tag editors always copy-writing ID3v1, they decide not to bother reading ID3v2 tags at all. Is this my imagination or are there such devices really still being produced and used?
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. ;-)
However, there are probably fewer players which only support ID3v1 than support 2.3 instead of 2.4.
Unless there is a pressing need to preserve ID3v2 for practical reasons listed above, I am afraid we should drop ID3v1 writing, because users consider mojibaking (ID3v1 written in ISO-88859-1 while player read them as SHIFT-JIS) being worse than having no information (player could not read ID3v2 and there was no ID3v1). The latter case is minor anyway, since by common sense most player would use filenames if there were no ID3v1.
I guess that you meant ID3v1 in the first sentence. It might be acceptable to disable writing an ID3v1 tag by default. It would be good to know what other tag editors do by default, and what a large variety of hardware players do if ID3v1 and ID3v2 tags are present. I suspect that the ID3v1 tag is ignored in most cases. It is a very small tag (128 bytes), so takes up negligible space in the file, but on the other hand may be of little use nowadays, and breaks when using non-ISO-8859-1 encodings (unless the user is comfortable managing that override themselves).
Now if we drop ID3v1, it paves a good ground for refactoring. Otherwise user interface design must cater the limitation of ID3v1.
This is not really the case. As ID3v2 is in nearly every way an improvement or extension of ID3v1, and ID3v1 is used as a fallback tag format, EasyTAG does not change the UI at all if writing both ID3v1 and ID3v2 tags. If writing only ID3v1 tags, you can see that a large portion of the tagging UI is hidden. EasyTAG is actually much worse at supporting all the (many) fields of ID3v2, and a new design is needed so that they can be shown in the UI without taking up more space.
-- http://amigadave.com/
Attachment:
signature.asc
Description: Digital signature