Rockbox mail archiveSubject: Re: Bad Recorded MP3s - may not be (solely) a DAC issue
Re: Bad Recorded MP3s - may not be (solely) a DAC issue
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Sun, 06 Nov 2005 10:24:04 +0100
On 06.11.2005, Bluechip wrote:
> At 10:33 05/11/2005, you wrote:
>> On 05.11.2005, Linus Nielsen Feltzing wrote:
>>>> 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,
>>> 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.
> (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.
(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.
>> 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...
>> >> 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
>>> corrupt? It just lacks the TOC, which is perfectly valid.
>>> 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...
Received on 2005-11-06