On 05.11.2005, Linus Nielsen Feltzing wrote:
> Bluechip wrote:
>> 1. Why does RB append a blank 4K ID3v2 header to the start of
>> every file?
> It's there for convenience, so that the file can be updated
> with a valid tag without rewriting the entire file.
Yes eaxactly. Rockbox did this all the time, but only for the
first file when using time split. Recently it does this for all
recorded files. One might argue that this might make joining the
files a bit harder, but why would you split them in the first
place if you want them joined? Recent version also always add
a xing header with complete (basic) info.
>> 2. Each ID3v2 tag is followed by 212 (0xD4) 0's ...which
>> afaict serve no purpose.
>> Is this a bug, or is there something I don't know?
> If there are 212 0's between the tag and the Xing header, then
> it's a bug.
The number of zero bytes before the xing header varies because
the size of the xing header varies depending on the mp3
samplerate. This isn't exactly a bug, at the start of the
recording rockbox doesn't know the size of the xing header
yet, but needs to reserve thespace in the file, so it simply
reserves the possible maximum. Most often the actual xing header
is smaller, hence the space. It has always been that way, but
due to changes in the handling the amount of zero bytes also
depends on the rockbox version.
This could be properly fixed by adjusting the size info of the
id3v2 tag to include this empty space.
>> 3. There is next a corrupt Xing (VBRI) header containing the
>> text "Rockbox - rocks your box" Again, is this helpful? Why
>> not put the text in the tag? I presume VBRFix will blat out
>> the comment when you try to make the file useable.
> It's a Xing header, not VBRI. What makes you think the tag is
> corrupt? It just lacks the TOC, which is perfectly valid. The
> text is there for the fun of it and nothing else.
Additionally, the text lies outside the defined data area of
the xing header, so it doesn't make the header invalid.
Received on Sat Nov 5 11:34:13 2005