> >>>> 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.
> > http://www.codeproject.com/audio/MPEGAudioInfo.asp#Anchor-4.-34080
> > (and others) seem to suggest that the header is always the
> > same length - can you point me in the right direction for the
> > information you have please?
>(1) This exact source tells you that the xing header data
> structure is *not* alwas the same size - it depends on which
> fields are present. The TOC makes the largest difference.
> Of course the maximum size is fixed.
I've read and read and read that page - and finally I think I may see the
"0x0001 - Frames field is valid"
"0x0001 - Frames field is PRESENT"
If so, then a full-and-working header will be 120bytes long.
So as long as we pick a frame which will always contain >= 120 useable bytes
then the audio frame which holds the xing header will always be the same
length when making rockbox recordings.
Better still pick a frame size which will also allow for a full LAME
>(2) Even when the xing data structure size is fixed, the whole
> xing header can't be, because the data structure resides in
> an mpeg audio frame. MPEG audio frames can only have certain
> lengths which are different for different MPEG version,
> layer and sample frequency.
We need to check how big the LAME header may be at maximum and what a
suitable audio-frame header would be to ensure the data-space required.
I shall leave that bit for someone who is in the position to go ahead from
there and make the relevant changes to the rockbox code ...once the LAME
header size is known it should be a trivial task.
> >> This could be properly fixed by adjusting the size info of
> >> the id3v2 tag to include this empty space.
> > Yes, that is probably the smartest option, as removing them
> > will mean copying the entire file.
>Copying the whole file on target while recording is simply out
>of question. That's why the headers are handled like they are
>handled in the first place.
>For the same reason, recorded files do not include a toc in the
>xing header - it would mean to scan the whole file. You can do
>that manually with the vbrfix plugin, then you will get an idea
>how long it can take...
I appreciate that xing header cannot be created during recording. But
patching the front of the MP3 file so that the recording is "valid" would
> >> >> 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.
> > It seems I must take a closer look at this frame to see
> > exactly what is going on.
> > I am all for "fun text" (just take a look at my games! LOL)
> > ...I just thought it would be nicer placed where it will be
> > read by people :)
>Perhaps both places, and including the version string.
>The goal for rockbox is of course to avoid the necessity to fix
>the recording files. To achieve this, it is necessary to
>frame-walk while recording. This would also enable it to always
>know the exact frame count (today we need to estimate for
>recordings where the MAS internal 20-bit frame counter
>saturates), and always reliably split at frame boundaries.
>One day I'll implement this...
Thanks (again) for your time, Jens.
Received on Sun Nov 6 23:11:52 2005