ID3v1.1: Difference between revisions

Revision as of 14:24, 10 March 2018

Although ID3v1 may well be easy to implement for programmers, it sure is frustrating for those with their own creative ideas. Since the ID3v1 tag had a fixed size and no space marked "Reserved for future use", there isn't really room for that much improvement, if you want to maintain compatibility with existing software.

Song title	30 characters
Artist	30 characters
Album	30 characters
Year	4 characters
Comment	28 characters
Album track	2 characters
Genre	1 byte

A person who discovered a way was Michael Mutschler, who made a quite clever improvement on ID3v1. Since all non-filled fields must be padded with zeroed bytes, it is a good assumption that all ID3v1 readers will stop reading the field when they encounter a zeroed byte. If the second last byte of a field is zeroed and the last one isn't, we have an extra byte to fill with information. As the comments field is too short to write anything useful, the ID3v1.1 standard declares that this field should be 28 characters, that the next byte always should be zero and that the last byte before the genre byte should contain which track on the CD this music comes from.

Additional Reading

ID3v1
ID3v2

Copyright

This material is copyrighted by Martin Nilsson, taken from ID3 made easy .

@@ Line 1: / Line 1: @@
-[[ID3v1]] may well be easy to implement for programmers, but it sure is frustrating for those with their own, creative ideas. Since the [[ID3v1]] tag had a fixed size and no space marked "Reserved for future use", there isn't really room for that much improvement, if you want to maintain compatibility with existing software.
+Although [[ID3v1]] may well be easy to implement for programmers, it sure is frustrating for those with their own creative ideas. Since the [[ID3v1]] tag had a fixed size and no space marked "Reserved for future use", there isn't really room for that much improvement, if you want to maintain compatibility with existing software.
 {|align=center border="0" cellpadding="5" cellspacing="5"
@@ Line 21: / Line 21: @@
 |}
-One who found a way out was Michael Mutschler who made a quite clever improvement on [[ID3v1]]. Since all non-filled fields must be padded with zeroed bytes its a good assumption that all [[ID3v1]] readers will stop reading the field when they encounter a zeroed byte. If the second last byte of a field is zeroed and the last one isn't we have an extra byte to fill with information. As the comments field is to short to write anything useful in the ID3v1.1 standard declares that this field should be 28 characters, that the next byte always should be zero and that the last byte before the genre byte should contain which track on the CD this music comes from.
+A person who discovered a way was Michael Mutschler, who made a quite clever improvement on [[ID3v1]]. Since all non-filled fields must be padded with zeroed bytes, it is a good assumption that all [[ID3v1]] readers will stop reading the field when they encounter a zeroed byte. If the second last byte of a field is zeroed and the last one isn't, we have an extra byte to fill with information. As the comments field is too short to write anything useful, the ID3v1.1 standard declares that this field should be 28 characters, that the next byte always should be zero and that the last byte before the genre byte should contain which track on the CD this music comes from.