Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: 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: 2005-11-06

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,
>> 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.
(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
>> 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...

Regards, Jens
Received on Sun Nov 6 10:24:28 2005


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa