Rockbox

Tasklist

FS#2147 - Corrupt files using time split feature

Attached to Project: Rockbox
Opened by Anonymous Submitter - Saturday, 17 April 2004, 21:31 GMT
Last edited by Rani Hod (RaeNye) - Thursday, 28 September 2006, 16:17 GMT
Task Type Bugs
Category Recording
Status Closed
Assigned To No-one
Operating System Archos Recorder
Severity High
Priority Normal
Reported Version
Due in Version Version 3.1
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I 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, 15:15 GMT
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.
Comment by Linus Nielsen Feltzing (linusnielsen) - Friday, 04 June 2004, 12:06 GMT

Can you try the latest (2004-06-05) build and see if it
works better?
Comment by Anonymous Submitter - Sunday, 12 September 2004, 16:16 GMT

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
Comment by Jochen Bitzer (rockpingu) - Sunday, 20 February 2005, 19:19 GMT

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 ;-)
Comment by David McIntyre (plugh) - Tuesday, 14 June 2005, 22:03 GMT

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.
Comment by Matthias Mohr (aka Massa) (mmohr) - Thursday, 27 April 2006, 14:16 GMT
Is this bug still present nowadays?
If nobody's having this bug anymore and does report it here, I'll close this task!
Comment by Jens Arnold (amiconn) - Thursday, 18 May 2006, 23:27 GMT
This bug is still present, though a lot less likely to occur since release 2.5.
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.
Comment by Eddy (bascule) - Tuesday, 06 March 2007, 20:05 GMT
Is this still a problem with all the recording code updates recently?

Loading...