flac playback issue - horrible skipping noise and track skipping to next

[svyr]

Hi,

been having this issue for years on various clip+ builds including I think the stable 3.13 and latest. (and on different devices and on the latest Xduoo X3 build)
on quite a few flac track it'd get to a part of a file then suddenly make a horrible skipping noise and track skipping to next
here's a sample broken track. It doesn't look to be a tag or card issue.

https://yadi.sk/d/R-CcgrudqK2y6

it seems like around 54-6 seconds there's a bit where it skips a second or so if played in aimp4 or audacity and keeps playing on (but on rockbox makes the horrible noise and skips to the next track). i don't really undestand how these make it into about as many as 1 in 30 tracks. perhaps unsafe removal of a fat32 drive but checkdisk doesn't seem to fix it .

Any ideas?

[svyr]

ps just to be clear, I realize the file is damaged but ideally I'd like rockbox to skip the damaged frames silently up to say 10, then without horrible noises go to the next track if the file is too far gone (or if under x frames are damaged play the next bit that works in the current file, like the desktop players do )

ps. Error converting to FLAC, '01 - Starships.flac' to '01 - Starships.flac'
   md5 did not match decoded data, file is corrupt.
   

[Mihail Zenkov]

Yes, your file broken - it have piece (1 MB)  filled by zero. You should use safe removal. Also try latest build it have some fixes for usb.

[svyr]

Yes, your file broken - it have piece (1 MB)  filled by zero. You should use safe removal. Also try latest build it have some fixes for usb.

thanks. yep you're right,
0x600000-0x700000 are all 0x00

 heh, i think at some point the clip+ build had really flakey usb support and I might've copied a couple of files across that way. (and it died. I could restore the card backup but the folder structure was changed around a few times, etc... we'll see how it goes)

is there any way to get a
a)'leniently ignore' option for rockbox so the behaviour is similar to desktop players or 1mb chunk is probably completely reasonable to ignore and skip to next (I'd be hard pressed to say it's not reasonable behaviour)
b) identify all the corrupted files ... I'm thinking I can try-convert them using Dbpoweramp batch convert then check the reported corrupted ones, but if anyone knows a better way - please let me know  (edit, nmv, this bit definitely works to validate the broken files: dbpoweramp -> test conversion (just tests the decoding) - via batch converter for the folder. )

[Mihail Zenkov]

a)'leniently ignore' option for rockbox so the behaviour is similar to desktop players or 1mb chunk is probably completely reasonable to ignore and skip to next (I'd be hard pressed to say it's not reasonable behaviour)

You right, probably we should add better reaction on broken files

b) identify all the corrupted files ... I'm thinking I can try-convert them using Dbpoweramp batch convert then check the reported corrupted ones, but if anyone knows a better way - please let me know

Not sure how do that on windows, on linux that can be done by command 'flac -t *.flac'.

[svyr]

a)'leniently ignore' option for rockbox so the behaviour is similar to desktop players or 1mb chunk is probably completely reasonable to ignore and skip to next (I'd be hard pressed to say it's not reasonable behaviour)

You right, probably we should add better reaction on broken files

b) identify all the corrupted files ... I'm thinking I can try-convert them using Dbpoweramp batch convert then check the reported corrupted ones, but if anyone knows a better way - please let me know

Not sure how do that on windows, on linux that can be done by command 'flac -t *.flac'.

thanks. if it currently ignores small broken chunks - maybe we could increase the tolerance... or at least do something to avoid the noise before skipping. makes me jump every time. I'll go fix up the files though. 1mb chunks missing out of 30mb tracks is no good

[svyr]

hmmm I'm not sure it's adding up.

There are 3500 FLAC files on the SDCard.
10 were corrupted . I've re-copied them from the NAS or re-ripped them re-tested test decoding with dbpoweramp . (that picks up corrupted frames of invalid checksums)
(no more Error: Watchdog timeout, possible CoreConverter crash
Encountered 'FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC'
md5 did not match decoded data, file is corrupt.
)

Here's the thing.


http://www.rockbox.org/tracker/task/12784?project=1&string=flac&search_in_details=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc

http://www.rockbox.org/tracker/task/12755?project=1&string=flac&search_in_details=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc
http://www.rockbox.org/tracker/task/12591?project=1&string=flac&search_in_details=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc
http://www.rockbox.org/tracker/task/12208?project=1&string=flac&search_in_details=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&order=dateopened&sort=desc
http://www.rockbox.org/tracker/task/12208?string=flac&project=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
http://www.rockbox.org/tracker/task/12591?string=flac&project=1&type%5B0%5D=2&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

there are many similar still open flyspray issues.
I'll keep an eye if it happens again but the general feeling from me is - while part of the issue was the definitely corrupted files, it happens far too frequently for it to just be related to those. (as in it skips far too often for it to add up to 10/3500 on shuffle).

thoughts? anything i can do to narrow it down. Reading the previous tickets (ones not relating to specific files or broken card) it seems like people are saying they can't repro it at times.

[Mihail Zenkov]

Latest build have some fixes for SD and internal drive. If you still have reproducible problem - report about it.

[svyr]

Latest build have some fixes for SD and internal drive. If you still have reproducible problem - report about it.

how late does it have to be I've updated to dev build a few weeks ago (say start of Feb)

Code: [Select]

Target: sansaclipplus
Target id: 66
Target define: -DSANSA_CLIPPLUS
Memory: 8
CPU: arm
Manufacturer: as3525
Version: 7d87ebb-160206
Binary: rockbox.sansa
Binary size: 600440
Voice format: 400
Actual size: 600432
RAM usage: 905792
Features: alarm:crossfade:dircache:flash_storage:lcd_bitmap:lcd_invert:pitchscreen:multivolume:multidrive_usb:quickscreen:radio:recording:recording_swcodec:recording_mic:rtc:swcodec:tagcache:charging:large_plugin_buffer:ab_repeat_buttons:lcd_flip:lcd_contrast:usb_power:usbstack:play_frequency
gcc: arm-elf-eabi-gcc (GCC) 4.4.4
ld: GNU ld (GNU Binutils) 2.20.1.20100303
Host gcc: gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)
Host system: Linux

[Mihail Zenkov]

35 hours ago

http://git.rockbox.org/?p=rockbox.git;a=shortlog

[svyr]

ok thanks I'll update my clip+/zips and ask XVertex to merge these into his Xduoo X3 builds

[Mihail Zenkov]

My changes related only to AMSv2 (clip+, zip, fuze v2, clip v2).

[svyr]

My changes related only to AMSv2 (clip+, zip, fuze v2, clip v2).

given it'd drop out intermittently I do have high hopes for the SD card patch.
could this be a flac decoder issue (probs not?) can we try a newer libflacdecoderOrWhateverItsCalled if available and comes from upstream?

[Mihail Zenkov]

could this be a flac decoder issue (probs not?)

Possible. Also possible we have few different problems but with same symptoms.

can we try a newer libflacdecoderOrWhateverItsCalled if available and comes from upstream?

Yes, but AFAIK we have many custom pathes and for update we should backport each changes from ffmpeg. So it not so easy.

[saratoga]

My changes related only to AMSv2 (clip+, zip, fuze v2, clip v2).

given it'd drop out intermittently I do have high hopes for the SD card patch.
could this be a flac decoder issue (probs not?) can we try a newer libflacdecoderOrWhateverItsCalled if available and comes from upstream?

You could try and make the FLAC decoder more robust against corrupt data, but there is no upstream to get code from. The parser is written for rockbox, so you'd have to improve it directly.

Edit:  Looking at that file, you get about 1000 samples of garbage when the data becomes corrupted.  Probably what happens is that the corrupted data begins mid frame, so the end of the current frame is corrupted, and then when the next frame is loaded the CRC fails and the decoder aborts.  FLAC includes a footer CRC that can be used to detect and mute corrupted frames like this, but we don't use it, probably to save battery life.  You could experiment with turning it on and muting output if the data is corrupt.  But I'm not sure how much sense that really makes verses just not feeding the decoder corrupted data.