From martin.benkert at gmail.com Fri Aug 7 12:21:41 2009 From: martin.benkert at gmail.com (Martin) Date: Fri, 7 Aug 2009 19:21:41 +0000 (UTC) Subject: [ID3 Dev] Order of additional information fields (ID3v2.4) Message-ID: Hi, I'd like to rephrase a question that has been asked on this list before, but there has never been a complete answer. Both ID3v2.3 and ID3v2.4 support additional information fields of frames ID3v2.3 section 3.3.1: Some flags indicates that the frame header is extended with additional information. This information will be added to the frame header in the same order as the flags indicating the additions. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions to the frame header, while not included in the frame header size but are included in the 'frame size' field, are not subject to encryption or compression. Id3v2.4 section 4.1: Some frame format flags indicate that additional information fields are added to the frame. This information is added after the frame header and before the frame data in the same order as the flags that indicates them. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions affects the 'frame size' field, but are not subject to encryption or compression. While the order for ID3v2.3 is clear Data Length indicator $xx xx xx xx Encryption method $xx Grouping indentificator $xx it appears to be ambiguous for ID3v2.4. For ID3v2.4 order of flags is 1) Grouping identity requires a single unsigned byte 2) Compression requires the presence of a data-length-indicator flag, but it does not add any information itself (unlike in ID3v2.3) 3) Encryption requires a single unsigned byte as the encryption method, and might optionally use a data-length-indicator flag 4) Unsynchronisation might optionally use a data-length-indicator flag 5) Data-length-indicator flag is an sync-safe 32-bit value This means that both the compression and the unsynchronisation flags will not add extra data and the resulting order of fields is Grouping indentificator $xx Encryption method $xx Data Length indicator 4* %0xxxxxxx But the ID3v2.4 standard still includes this statement from ID3v2.3 I.e. the four bytes of decompressed size will precede the encryption method byte. which makes no sense since there is no additional data related to compression. It will set - just like encryption and unsynchronisation might - simply the data-length-indicator flag. However it seems some people interpret this statement in the way that the order should be Grouping indentificator $xx Data Length indicator 4* %0xxxxxxx Encryption method $xx I think the first order is correct (and it is the only one that make sense to me). Jess Harpur has also voted for this order on this mailing list http://article.gmane.org/gmane.comp.multimedia.id3v2/610 However, the only implementation I was able to find that supports these fields is jaudiotagger v1.0.9 which uses the second order. So, right now its 2:1. And that's not good. While its easy to identify the fields while reading (encryption method symbol is in the range 0x80,...,0xf0, and data-length-indicator bytes are %0xxxxxxx), it is still not clear to me how to write them in a standard compliant way. I would really appreaciate your opinion about this. Thanks, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mathiaskunter at yahoo.de Sat Aug 15 01:29:18 2009 From: mathiaskunter at yahoo.de (Mathias Kunter) Date: Sat, 15 Aug 2009 08:29:18 +0000 (GMT) Subject: [ID3 Dev] Order of additional information fields (ID3v2.4) In-Reply-To: References: Message-ID: <313864.343.qm@web27001.mail.ukl.yahoo.com> Hi, I think that the statement "the four bytes of decompressed size will precede the encryption method byte" within ID3v2.4 simply has been overlooked when adopting the text from the ID3v2.3 specification (a classical copy & paste error). I therefore assume that this statement is *not* correct within ID3v2.4 - this is the only thing that makes sense. I think that the ID3v2.4 statement "this information is added [...] in the same order as the flags that indicates them" should be considered as the "stronger" rule. I'd therefore say you should write the additional information bytes in the order as the flags indicate them. If you've found an ID3v2 implementation which does it the other way round, you could contact them and ask them to fix it. The statement in question should be removed (or adopted) within the ID3v2.4 specification as it causes confusion and is definitely incorrect. (Who is responsible for that?) Furthermore, there seems to be a typo within the statement "A 'Data Length Indicator' byte MUST be included in the frame." from section 4.1.2 "k - Compression". It should either be "A 'Data Length Indicator' bit MUST be included in the frame." or "A 'Data Length Indicator' MUST be included in the frame.". A data length indicator *byte* however makes no sense to me and also causes confusion - it should be the data length indicator *bit* in my opinion. Regards, Mathias K. ________________________________ Von: Martin An: id3v2 at id3.org Gesendet: Freitag, den 7. August 2009, 21:21:41 Uhr Betreff: [ID3 Dev] Order of additional information fields (ID3v2.4) Hi, I'd like to rephrase a question that has been asked on this list before, but there has never been a complete answer. Both ID3v2.3 and ID3v2.4 support additional information fields of frames ID3v2.3 section 3.3.1: Some flags indicates that the frame header is extended with additional information. This information will be added to the frame header in the same order as the flags indicating the additions. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions to the frame header, while not included in the frame header size but are included in the 'frame size' field, are not subject to encryption or compression. Id3v2.4 section 4.1: Some frame format flags indicate that additional information fields are added to the frame. This information is added after the frame header and before the frame data in the same order as the flags that indicates them. I.e. the four bytes of decompressed size will precede the encryption method byte. These additions affects the 'frame size' field, but are not subject to encryption or compression. While the order for ID3v2.3 is clear Data Length indicator $xx xx xx xx Encryption method $xx Grouping indentificator $xx it appears to be ambiguous for ID3v2.4. For ID3v2.4 order of flags is 1) Grouping identity requires a single unsigned byte 2) Compression requires the presence of a data-length-indicator flag, but it does not add any information itself (unlike in ID3v2.3) 3) Encryption requires a single unsigned byte as the encryption method, and might optionally use a data-length-indicator flag 4) Unsynchronisation might optionally use a data-length-indicator flag 5) Data-length-indicator flag is an sync-safe 32-bit value This means that both the compression and the unsynchronisation flags will not add extra data and the resulting order of fields is Grouping indentificator $xx Encryption method $xx Data Length indicator 4* %0xxxxxxx But the ID3v2.4 standard still includes this statement from ID3v2.3 I.e. the four bytes of decompressed size will precede the encryption method byte. which makes no sense since there is no additional data related to compression. It will set - just like encryption and unsynchronisation might - simply the data-length-indicator flag. However it seems some people interpret this statement in the way that the order should be Grouping indentificator $xx Data Length indicator 4* %0xxxxxxx Encryption method $xx I think the first order is correct (and it is the only one that make sense to me). Jess Harpur has also voted for this order on this mailing list http://article.gmane.org/gmane.comp.multimedia.id3v2/610 However, the only implementation I was able to find that supports these fields is jaudiotagger v1.0.9 which uses the second order. So, right now its 2:1. And that's not good. While its easy to identify the fields while reading (encryption method symbol is in the range 0x80,...,0xf0, and data-length-indicator bytes are %0xxxxxxx), it is still not clear to me how to write them in a standard compliant way. I would really appreaciate your opinion about this. Thanks, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul_t100 at fastmail.fm Thu Aug 20 06:21:05 2009 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 20 Aug 2009 14:21:05 +0100 Subject: [ID3 Dev] Order of additional information fields (ID3v2.4) In-Reply-To: <313864.343.qm@web27001.mail.ukl.yahoo.com> References: <313864.343.qm@web27001.mail.ukl.yahoo.com> Message-ID: <4A8D4DC1.5070909@fastmail.fm> Hi "the four bytes of decompressed size will precede the encryption method byte" is certainly wrong as it doesn't exist. I think after rereading this section half a dozen time that you right and I will modify jaudiotagger accordinlgy. However jaudiotagger only reads these values it doesn't write them so : Do we know of any other application that write the information misunderstood this Can we publish 2.4.1 on the website with this amendment (and any agreed others) so others don't repeat the mistake It could be good practise to write the read code to check both Data Length/Encryption and Encryption/Data Length order when both Compression and Encryption are set to cope with incorrectly written files, but not sure if safe algorithm is possible. Anyone know of any application that compresses and encrypts frame in 2.4. Paul Mathias Kunter wrote: > Hi, > > I think that the statement "the four bytes of decompressed size will > precede the encryption method byte" within ID3v2.4 simply has been > overlooked when adopting the text from the ID3v2.3 specification (a > classical copy & paste error). > I therefore assume that this statement is *not* correct within ID3v2.4 > - this is the only thing that makes sense. I think that the ID3v2.4 > statement "this information is added [...] in the same order as the > flags that indicates them" should be considered as the "stronger" rule. > > I'd therefore say you should write the additional information bytes in > the order as the flags indicate them. If you've found an ID3v2 > implementation which does it the other way round, you could contact > them and ask them to fix it. > > The statement in question should be removed (or adopted) within the > ID3v2.4 specification as it causes confusion and is definitely > incorrect. (Who is responsible for that?) > > Furthermore, there seems to be a typo within the statement "A 'Data > Length Indicator' byte MUST be included in the frame." from section > 4.1.2 "k - Compression". It should either be "A 'Data Length > Indicator' bit MUST be included in the frame." or "A 'Data Length > Indicator' MUST be included in the frame.". A data length indicator > *byte* however makes no sense to me and also causes confusion - it > should be the data length indicator *bit* in my opinion. > > Regards, > Mathias K. > > > > ------------------------------------------------------------------------ > *Von:* Martin > *An:* id3v2 at id3.org > *Gesendet:* Freitag, den 7. August 2009, 21:21:41 Uhr > *Betreff:* [ID3 Dev] Order of additional information fields (ID3v2.4) > > Hi, > > I'd like to rephrase a question that has been asked on this list before, > but there has never been a complete answer. > > Both ID3v2.3 and ID3v2.4 support additional information fields of frames > > ID3v2.3 section 3.3.1: > Some flags indicates that the frame header is extended with > additional information. This information will be added to the frame > header in the same order as the flags indicating the additions. I.e. > the four bytes of decompressed size will precede the encryption > method byte. These additions to the frame header, while not included > in the frame header size but are included in the 'frame size' field, > are not subject to encryption or compression. > > Id3v2.4 section 4.1: > Some frame format flags indicate that additional information fields > are added to the frame. This information is added after the frame > header and before the frame data in the same order as the flags that > indicates them. I.e. the four bytes of decompressed size will precede > the encryption method byte. These additions affects the 'frame size' > field, but are not subject to encryption or compression. > > While the order for ID3v2.3 is clear > > Data Length indicator $xx xx xx xx > Encryption method $xx > Grouping indentificator $xx > > it appears to be ambiguous for ID3v2.4. For ID3v2.4 order of flags is > > 1) Grouping identity requires a single unsigned byte > 2) Compression requires the presence of a data-length-indicator flag, > but it does not add any information itself (unlike in ID3v2.3) > 3) Encryption requires a single unsigned byte as the encryption method, > and might optionally use a data-length-indicator flag > 4) Unsynchronisation might optionally use a data-length-indicator flag > 5) Data-length-indicator flag is an sync-safe 32-bit value > > This means that both the compression and the unsynchronisation flags will > not add extra data and the resulting order of fields is > > Grouping indentificator $xx > Encryption method $xx > Data Length indicator 4* %0xxxxxxx > > But the ID3v2.4 standard still includes this statement from ID3v2.3 > > I.e. the four bytes of decompressed size will precede the encryption > method byte. > > which makes no sense since there is no additional data related to > compression. > It will set - just like encryption and unsynchronisation might - > simply the > data-length-indicator flag. However it seems some people interpret this > statement in the way that the order should be > Grouping indentificator $xx > Data Length indicator 4* %0xxxxxxx > Encryption method $xx > > I think the first order is correct (and it is the only one that make > sense to > me). Jess Harpur has also voted for this order on this mailing list > http://article.gmane.org/gmane.comp.multimedia.id3v2/610 > > However, the only implementation I was able to find that supports > these fields > is jaudiotagger v1.0.9 which uses the second order. > > So, right now its 2:1. And that's not good. > > While its easy to identify the fields while reading (encryption method > symbol > is in the range 0x80,...,0xf0, and data-length-indicator bytes are > %0xxxxxxx), > it is still not clear to me how to write them in a standard compliant way. > > I would really appreaciate your opinion about this. > > Thanks, > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > > For additional commands, e-mail: id3v2-help at id3.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org