# Understanding ID3 MCDI frame size **URL:** \ **Category:** Support\ **Created:** [April 22, 2016, 1:52pm UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878 "2016-04-22T13:52:33Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![lelouche](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/46a35a/32.png) [@lelouche](https://community.mp3tag.de/u/lelouche)\ **Post date:** [April 22, 2016, 1:52pm UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/1 "2016-04-22T13:52:33Z")
Hello I'm a little bit how Mp3Tag handle MCDI frame and specifically around such frame size. I'm expecting such frame to be organized as follows: - MCDI (4 bytes) - xx xx xx xx (4 bytes for size) - xx xx (2 bytes for flags) - size bytes for MCDI content - Next frame starting here. For a reason I don't understand Mp3Tag considers size + 1 bytes of content. Can someone explain where this is coming from ? Thanks ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [April 22, 2016, 2:43pm UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/2 "2016-04-22T14:43:04Z")
Here is the definition by the id3 org. [http://id3.org/id3v2.3.0#sec4.5](http://id3.org/id3v2.3.0#sec4.5) Here you find the list of fields in MP3tag: [https://docs.mp3tag.de/mapping](https://docs.mp3tag.de/mapping) Where is MCDI? ---
**Author:** ![lelouche](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/46a35a/32.png) [@lelouche](https://community.mp3tag.de/u/lelouche)\ **Post date:** [April 28, 2016, 8:23am UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/3 "2016-04-28T08:23:40Z")
As you can see in the spec you pointed, MCDI is a valid frame. "4.5 MCDI [#sec4.5 Music CD identifier]" But I don't understand how Mp3Tag consider this and basically tell if tag is bad or not. I've found some MP3 with bad MCDI frame size but Mp3tag says it is a valid tag while if I fix this size, it becomes "bad id3". Any ideas ? ---
**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\ **Post date:** [April 28, 2016, 10:32am UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/4 "2016-04-28T10:32:22Z")
Perhaps the testing equipment is not right? Perhaps the method to "correct" an alleged fault is not correct? Mp3tag is the name of the program for tagging. It does not explain mp3 tags in general. ---
**Author:** ![lelouche](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/46a35a/32.png) [@lelouche](https://community.mp3tag.de/u/lelouche)\ **Post date:** [April 28, 2016, 12:06pm UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/5 "2016-04-28T12:06:41Z")
> [@ohrenkino](#): > > Perhaps the testing equipment is not right? > Perhaps the method to "correct" an alleged fault is not correct? > > Mp3tag is the name of the program for tagging. It does not explain mp3 tags in general. The point is that Mp3Tag does not say TAG is bad when it should. Who can answer this if I give you a MP3 file with tag corrupted (MCDI wrong size) ? ---
**Author:** ![Sachlich](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/57b2e6/32.png) [@Sachlich](https://community.mp3tag.de/u/Sachlich)\ **Post date:** [July 3, 2022, 8:24am UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/6 "2022-07-03T08:24:21Z")
This is an old thread, but since I ran into the exact same issue, and this thread was the only source I could find on the web that even raises the question of MCDI frame size, I thought I should add the answer that I found out eventually. ### What's the issue? Like the OP, I encountered various files with an MCDI frame in their ID3v2.3 tag. In many (all?) these cases, the size of that frame appeared to be off-by-one and the following tag (typically TLEN) started one byte later than expected. This threw off my own decoder. It didn't help that the content of that frame was binary data (the dump of a CD's TOC), whose format I had trouble finding accurate documentation for. ### What's the reason? In short, the [unsynchronisation scheme](https://id3.org/id3v2.3.0#The_unsynchronisation_scheme). It turns out the unsynchronisation bit was set in the offending ID3v2.3 header. That causes all sequences of $FF Fx bytes in the body of the tag to be replaced with $FF 00 Fx. Most frames do not contain data where such byte sequences would even show up. But the binary data contained in the MCDI frame seems to regularly end in $FF FF – which becomes $FF 00 FF after unsynchronisation is applied. Now, unfortunately, this feature is documented somewhat poorly. The ID3v2.3 spec clearly says that the size field in the tag header is computed _after_ unsynchronisation is applied. However, what it does not say explicitly is that the size of frames apparently is computed _before_ unsynchronisation – that's because unsynchronisation is applied to the tag as a whole. Moreover, this was [changed](https://id3.org/id3v2.4.0-changes) in ID3v2.4, where unsynchronisation is now applied per frame, such that frame sizes are finally 'correct'. ### What's the implication More fun and special casing for decoders... For ID3v2.3, you cannot decode or skip frames without looking at every byte in them. Worse, in 2.3, the frame size itself actually is subject to the unsynchronisation scheme. That is, if a size value happens to contain a $FF byte, you better check whether it's followed by $00 and skip that. ---
**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\ **Post date:** [July 3, 2022, 9:29am UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/7 "2022-07-03T09:29:49Z")
Welcome and thanks for your detailed explanation! ---
**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\ **Post date:** [August 2, 2022, 9:30am UTC](https://community.mp3tag.de/t/understanding-id3-mcdi-frame-size/17878/8 "2022-08-02T09:30:34Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.