From: Dave Hooper <dave_at_beermex.com>
Date: Tue, 29 Jun 2010 21:47:40 +0100

Right- any bug reports about glitches are usually followed up with responses
to confirm that the file isn't corrupted (I think there are tools that
enable doing this standalone, though not certain). Glitching audio on
corrupted files definitely better than rockbox crashes/infinite loops on
corrupted files (especially on e.g. h1xx where you need to stick something
in the reset hole) so IMHO we should keep the crc check in.
Not a big fan of making it configurable via settings even if enabled by
default - maybe only those users who have already run offline codec-specific
crc checks on all their audio files would ever turn it off. And that 1%
translates to 12mins extra runtime for a device with 20hrs rockbox runtime,
for example.

As for mp3 encoders that put garbage in the crc fields - sure, maybe the
setting would help there - but really the right fix would be to fix the file
and/or not use an encoder that doesn't meet the corresponding spec. If there
was a don't-do-crc config option, it would (in this use-case) make complete
sense if it were per-file somehow, rather than global (again IMHO)

On 29 Jun 2010 19:34, "Nils Wallménius" <nils.wallmenius_at_gmail.com> wrote:

On Tue, Jun 29, 2010 at 6:37 PM, Dave Hooper <dave_at_beermex.com> wrote:
> 'How often do files just go...
I don't really download files very often but if crc checks would fail
often i think we would get quite some bug reports about glitches in
the sound or files that won't play depending on how the individual
decoder handles this. But i see your point so do you think a setting
that keeps it enabled as default would be ok or would you rather i'd
leave it alone.

I think at least the vorbis loop can be optimized a little but it
doesn't really change my opinion of this checking.

And as lear stated mp3 does it as well as a bunch of others.

Nils
Received on 2010-06-29