Rockbox

Tasklist

FS#10441 - USB transfer as Rockbox USB corrupts flac files

Attached to Project: Rockbox
Opened by Chris (churrell2375) - Thursday, 16 July 2009, 00:44 GMT
Last edited by Dave Hooper (stripwax) - Friday, 30 October 2009, 12:55 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Version 3.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Many flac files copied to device when connected as Rockbox USB device, rather than original firmware USB device become corrupted.
This also happen with the c200. Unknown if other audio formats are affected. Operating system typically used for transfer is Windows XP 64bit. The problem is not the files themselves, because the original ones from the computer play fine on the computer, or when the files are transferred to the device using the original firmware USB device.
However, the files that were corrupted on the device, when played on the computer show signs of skips and pops, but still play through the problem areas. Rockbox skips to the next song when the problems are encountered on the device.
This task depends upon

Closed by  Dave Hooper (stripwax)
Friday, 30 October 2009, 12:55 GMT
Reason for closing:  Invalid
Additional comments about closing:  Problem with the audio files themselves, not a problem with USB/corruption
Comment by Marc Guay (Marc_Guay) - Thursday, 16 July 2009, 12:00 GMT
Similar problems here. e200 + v3.3 w/ FLAC.
Comment by Frank Gevaerts (fg) - Thursday, 16 July 2009, 17:40 GMT
Does this also happen with a current build?
Comment by Dave Hooper (stripwax) - Thursday, 23 July 2009, 13:12 GMT
Is it definitely a file-corruption issue? If you transfer the file BACK from your device to your computer (e.g. into a different folder on your PC), does it differ from the original ? Possibly the FLAC file itself is just incompatible with rockbox (which may point to an issue with the FLAC codec, rather than an issue with USB file corruption)
Comment by Boris Gjenero (dreamlayers) - Friday, 31 July 2009, 03:30 GMT
The original report says the files play properly when they are transferred using the original firmware. This definitely seems like a file corruption issue.

Such a problem should not be limited to FLAC files. It just shows up there because FLAC files are big (giving more opportunities for errors) and the Rockbox FLAC decoder doesn't recover from file corruption very well.
Comment by Sander Sweers (infirit) - Friday, 31 July 2009, 07:22 GMT
I noticed the same with flac files but did not have time to look into this more. What do you normally do to check file corruption,a sha or md5 sum? Or a diff?
Comment by Boris Gjenero (dreamlayers) - Friday, 31 July 2009, 12:40 GMT
When both files reside on the same hard drive, a sha or md5 sum can be a lot faster, because the drive doesn't have to seek back and forth between the files.

In this case, it might be useful to see how files differ. On Windows you can use "fc /b" and in Unix you can use "cmp -b". Redirect the output to a file or pipe it to the head command, because there may be a lot of output.
Comment by Sander Sweers (infirit) - Sunday, 02 August 2009, 15:29 GMT
The "corruption" was actually in the source material and did not occur during transfer. I did a transfer under linux and ran a md5sum and compared them to the original and all have the same sum.

I will do some more testing with larger files to see if this will trigger it. So for now I can not reproduce this.
Comment by Dave Hooper (stripwax) - Sunday, 18 October 2009, 02:01 GMT
Does someone (Mark_guay? infrit?) have a reproducible example with evidence that the file transfered TO the device and then subsequently transferred BACK off the device differs from the original? Until then, we have no evidence that there is any file corruption. so I don't know if there is a problem with usb transfer, or whether rockbox just behaves differently from PC player on corrupted source material.
If nothing happens on this task in the next (say) three weeks or so, it will be closed...
Comment by Marc Guay (Marc_Guay) - Sunday, 18 October 2009, 12:07 GMT
I haven't noticed anything odd recently. This was likely a problem with the source files.
Comment by Sander Sweers (infirit) - Sunday, 18 October 2009, 13:05 GMT
See my comment earlier, I did a compare of the files and could not find any problems. My case it was artifacts in the source which could be decoding errors (not rockbox fault) but it was not caused by the transfer.
Comment by Dave Hooper (stripwax) - Friday, 30 October 2009, 12:54 GMT
Ok, closing

Loading...