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: Mon, 07 Nov 2005 02:09:12 +0100
On 06.11.2005, Bluechip wrote:
>>> (and others) seem to suggest that the header is always the
>>> same length - can you point me in the right direction for
>>> 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
>> fields are present. The TOC makes the largest
>> Of course the maximum size is fixed.
> I've read and read and read that page - and finally I think I
> may see the confusion.
> "0x0001 - Frames field is valid"
> actually mean
> "0x0001 - Frames field is PRESENT"
Yes it does mean that.
> 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 header-extension too.
>> (2) Even when the xing data structure size is fixed, the
>> xing header can't be, because the data structure resides
>> an mpeg audio frame. MPEG audio frames can only have
>> 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.
Rockbox already does a (simplified) selection of a suitable frame
The point is that the possible frame sizes depend e.g. on
the sample frequency, and there is *no* frame size that is valid
for all sample frequencies. We don't know the recording sample
frequency beforehand, at least with s/pdif.
>> >> 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
>>> 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
> 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 be simple.
Yes. It requires some understanding of the id3v2 standard
though, so I wouldn't call it trivial. Should be fairly easy
>> 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...
> LOL ;)
That's was absolutely serious. I'll do that before the next
release, I promise.
Received on 2005-11-07