[ID3 Dev] Order of additional information fields (ID3v2.4)

[Martin]

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