I really think they are complementary. Crc protects against corrupted
frames/bitstream and enables resync without necessarily decoding and playing
what might otherwise be a valid but garbage (and noisy) frame. You (should)
get a much more pleasant gap/skip instead of audio hell. Whereas checking
th
pondlife wrote:
I'd vote to remove CRC checks, but also maybe put a little effort in to
check places where corrupt input data might cause crashes/lockups - e..g.
ensuring loop counts are sane.
We ought to be able to pass random data into any codec without fear of a
crash - maybe try renaming som
>
> The proof is in the pudding... Could you keep it on Flyspray - I'd
> certainly use it, if it saves a few MHz on MP3.
>
I don't think the savings is that large. If it is we should probably disable
CRC checking on Mp3 files. Its mostly worthless anyway.
On Wed, 30 Jun 2010 14:31:12 +0100
"pondlife" wrote:
> The proof is in the pudding... Could you keep it on Flyspray - I'd
> certainly use it, if it saves a few MHz on MP3.
FWIW mp3_encoder doesn't generate CRC
--
Rafaël Carré
The proof is in the pudding... Could you keep it on Flyspray - I'd
certainly use it, if it saves a few MHz on MP3.
pondlife
That the crc is correct is in no way a guarantee that the data is in
spec. However as there seems to be several people against this i'll
drop the idea and just use it privately.
Nils
Jonathan Gordon wrote:
> If we want error checking then we should use whatever the codec gives
> up (crc in this case), especially when the gain isnt really that much.
I think that it is much more important to have robust codecs instead of
depending on optional and possibly wrong checksum.
Think
Am 30.06.2010 10:35, schrieb pondlife:
I'd hope in most places it shouldn't need explicit error checking, just
correctly-written code. ;-)
pondlife
I think "correctly written" basically means extra error checking for
faulty/corrupted input data.
Best regards.
>> We ought to be able to pass random data into any codec without fear of a
>> crash - maybe try renaming some other files to .mp3 and playing them?
> To be honest,I think that is silly, if the point of removing this
> check is to speed the codec up, wouldnt it be negated by any error
> checking w
On 30 June 2010 16:21, pondlife wrote:
> We ought to be able to pass random data into any codec without fear of a
> crash - maybe try renaming some other files to .mp3 and playing them?
>
To be honest,I think that is silly, if the point of removing this
check is to speed the codec up, wouldnt it
I'd vote to remove CRC checks, but also maybe put a little effort in to
check places where corrupt input data might cause crashes/lockups - e..g.
ensuring loop counts are sane.
We ought to be able to pass random data into any codec without fear of a
crash - maybe try renaming some other files t
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
corrupte
On Tue, Jun 29, 2010 at 6:37 PM, Dave Hooper wrote:
> 'How often do files just go bad' - well I guess part of the reason for the
> crc is that nobody really knows the answer to that. Ever downloaded a
> corrupted file from the internet, or a torrent with missing (unavailable)
> chunks? Without crc
On 2010-06-29 18:37, Dave Hooper wrote:
do we do crc checking on mp3?
Yes. This has in fact caused problems from time to time, as not all
encoders fill in the CRC field properly, when present.
--
Magnus
'How often do files just go bad' - well I guess part of the reason for the
crc is that nobody really knows the answer to that. Ever downloaded a
corrupted file from the internet, or a torrent with missing (unavailable)
chunks? Without crc checking the frame, you could easily crash rockbox with
malf
Several of our codecs do crc checking on data before playing it back.
In my opinion it is completely wasted battery time and cpu cycles, how
often do files just go bad? I found a profile run from an ipod video
and crc checking takes about 1% of the time spent decoding vorbis on
that.
So is it ok to
16 matches
Mail list logo
