This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#2147 - Corrupt files using time split feature
Attached to Project:
Rockbox
Opened by Anonymous Submitter - Saturday, 17 April 2004, 23:31 GMT+2
Last edited by Rani Hod (RaeNye) - Thursday, 28 September 2006, 18:17 GMT+2
Opened by Anonymous Submitter - Saturday, 17 April 2004, 23:31 GMT+2
Last edited by Rani Hod (RaeNye) - Thursday, 28 September 2006, 18:17 GMT+2
|
DetailsI am using an Archos JBR 20 (black corners), Archos
Rom vs. 1.28, and Rock box 2.2 version daily build 20040410, Quality=7, freq=44100, independant frames, using line-in. I make long time 24/24 hrs. recordings (from 4 hrs. - by day- to 16hrs -by night- per file). Using the deep unload battery feature, the JBR is always connected to the AC adapter. When I set the recorder manually, nearly all files are editable with Sound Forge 6.0, especially after having run them through MP3fixer or VBRfix. Most problems occur with files > 1 GB, but I can usually get them mended. However I do get some plops and glitches in some songs. Of course I want to make the long files smaller using the time split feature. When I use time split (= 4 hrs) I usually get 1 or 2 good files at the beginning, and the rest is corrupt. These bad files can only be played with the Archos and apparently with the Thomsom MP3pro-player (I tried it today, but can't see if they 3 or 4 hrs.long files). They cannot be split with MP3splt or MP3 directcut or be edited using Sound Forge or Magix Music Cleaning Lab. I have conducted some simple testrecordings. First my 15 min recordings gave bad files. Then I disabled the independant frames setting and my 10 minutes files were all OK, but my 1 hr files were corrupt. My 20 minutes files were also bad, but when I lowered the quality level to 6 (=Q6) the 20 min files were OK. Most importantly, my 4 hrs files at Q6 (6 bad ones save the first file) and Q7(nrs 1, 2, 8, 9, and 10 good, this is exceptional, and nrs 3-7, 11 and 12 bad) were no good. I have got some corrupt files in stock, the smallest of which is 17 MB. I have run scandisk once and chkdsk / f several times. HW-info: ROM 1.28; mask 0x0302; USB: positive; ATA: 0x200, master; PR: positive; Flash: M=BF D=D6; ROM CRC: 0x222F V1 (I've only just registered at Sourceforge.net) s.handjeklap email address: lverkaik@zonnet.nl |
This task depends upon
Closed by Daniel Stenberg (bagder)
Saturday, 19 May 2007, 17:15 GMT+2
Reason for closing: Later
Additional comments about closing: Moved to the new KNOWN_ISSUES files since this is unlikely to be fixed in a forseeable time.
Saturday, 19 May 2007, 17:15 GMT+2
Reason for closing: Later
Additional comments about closing: Moved to the new KNOWN_ISSUES files since this is unlikely to be fixed in a forseeable time.
Can you try the latest (2004-06-05) build and see if it
works better?
Thank you for your attention to my problem. In the mean
time I have tried several daily builds and made a couple of
hundreds of trial recordings of 4 hrs. duration each. I used
both dependant and independant frame settings and changed
the prerecording times. However, all was in vain, the problem
still persists. Only once did I have 12 good recordings in a
row. This week I made 50 recordings of which only 3 were
good. I hope you can come up with the right solution for me.
Leen Verkaik
Same problem
Hello, I have encountered exactly the same behaviour
(Jukebox Recorder / Rockbox 2.4). I tested it on several
devices (own and from friends). On 5 (!) Jukebox recorders
with harddisks from 10GB to 80GB it's exactly as you
described. I also used chkdsk /f at first.
I hope this bug can be fixed soon.
Joachim
j_bitzer@web.de
I stored your e-mailaddress. In case of any solution I will tell
you too ;-)
6/6 build exhibits the same problem. It seems that no mp3
header is written to the splits files in autosplit mode.
When the files are copied together (cat file1 file2 file3 >
file4) or (copy file1+file2+file3 file4) the resulting mp3
can be played outside the player.
If nobody's having this bug anymore and does report it here, I'll close this task!
It's a bug in the MAS. It starts bitshifting data on occasion. High load on the MAS makes this behaviour more likely (high recording level, high quality setting, high sample rate). It's impossible to avoid, but there are plans to implement a recording 'framewalker' that checks recorded data and restarts recording when the MAS starts delivering bitshifted data. That won't happen before release 3.0, but hopefully before 3.1.