Hi Weiwu On 2014-08-09 17:52, Zhang Weiwu <zhangweiwu realss com> wrote:
First: the choice of using RED in the UI. Currently easytag display unsaved tags and tags in unsupported version in RED color, prompting users to save it in a supported version (ID3 2.4). The color RED usually mean "stop, caution and do not do it", while in EasyTag it means "please proceed on saving it", almost the opposite meaning. RED is not suitable to carry the concept of need-to-save, which usually is done by a telltale prefix: *. The other connotation connected to RED is that: once the file is saved, it may not be compatible with some devices or players, hence RED for "Caution". However it is rather far-fetching for users to conceptualize this, especially not in the musical mood.
Yes, I also think that red is a poor choice of colour for indicating unsaved changes. This is why, before 2.2.0 was released, I changed the default for indicating unsaved changes to use bold text instead:
https://git.gnome.org/browse/easytag/commit/?h=easytag-2-2&id=4ddf4c8465cc39db88d21379d3cd298a8c372327Unfortunately, this is only useful for people who have never used EasyTAG before, as if they have a saved configuration it will override the default.
In the future, a prefix may be better, and I think it is a good suggestion. A related issue is that EasyTAG currently does not display the nature of the unsaved changes (although it is possible to undo changes per-file, but only those visible to the user can be undone, whcih does not include ID3v2 version changes). Using some more granular way of indicating that change, for example with an icon, might be useful, but it needs some more thought.
And second: the choice of using ID3 v2.4 program-wide.UTF-8 and 2.3 does not (only UTF-16 and ISO-8859-1). While UTF-8 is a (in many ways) better encoding for most users, its main benefit is to save space in tags. Trading that benefit for reduced compatibility may not be worth it.Can I assume that the field width of ID3 tag is limited by number of bytes, instead of number of characters, hence "main benefit is to save space"?
ID3v2 tags can be large (ID3v1 tags are limited to 30 bytes for most fields), but yes, the main benefit of using different encodings in ID3v2 is to reduce the size of the tag data. The amount of space saved is probably negligible, given the length of most tag fields.
If so, you are using a western assumption! The Chinese and Japanese ideographs are saved in less number of bytes in UTF16 than save in UTF-8. Just randomly copy some Chinese text and save them in UTF16 and UTF-8 to compare the result text file length.
Yes, very true! I was extrapolating to all users based on my music collection.
Had EasyTag be written by a Chinese, he could as well say: "We default to ID3 2.3 because this version saves in UTF16, with its main benifit of saving spaces in tags. Trading that benefit for reduced compatibility may not be worth it." Should I say EasyTag is presumptuous? No, we the Chinese are worse. From my observation, most Chinese-made players and tag editors did not move forward to ID3v2 at all. Most default to ID3v1, simply taking any data as Chinese local encoding, hence all of them show junk text with legit ID3v1 tags that contains umlauts. Luckyly so few Chinese listen to German music that we presumptuously ignore their inconvenience, just like our online music stores conveniently repalcing é/ë with e for any european music imported. In fact, if a text is in a Latin-based language, you get more characters per byte by saving in ISO-8859-1 than in UTF-8. If it is in a ideographic language, you get more characters per byte by saving in UTF-16 than in UTF-8. There is nothing to lose by not using UTF-8 at all. The beauty of UTF-8 is that we don't have to choose between the two scenarios, simple in the thinking and implementation.
Yes, this is a well-written evaluation of the problem, and my (admittedly western) viewpoint of it. From my perspective, UTF-8 is the easiest encoding to handle because it is used for strings by GTK+ and (to a lesser extent) GLib internally. This presents problems when handling filenames in a different encoding, but that is a relatively well-understood problem with reasonable solutions. Most tag formats other than ID3 also use UTF-8 encoding (either by default or exclusively), so ID3 is slightly awkward, but this is for the most part due to its widespread use and informal standardisation process.
EasyTAG has code to convert between UTF-16 and UTF-8 when necessary, and plenty of code to override the encoding for ID3v1 and ID3v2 tags, which can hopefully cover most of the use cases that one encounters, including the one you mentioned about hardware players using a local encoding.
My thinking is that if I changed the default ID3v2 version to be 2.3, I would get fewer bug reports from users about their ID3 tags not being read by a player, compared to the current situation where this happens occasionally. Then, if users changed their settings to use ID3v2.4, because they knew that it was compatible with their players, it would (possibly) save them some space and require fewer encoding conversions.
-- http://amigadave.com/
Attachment:
signature.asc
Description: Digital signature