Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Recording
  • Assigned To No-one
  • Operating System Archos Recorder
  • Severity High
  • Priority Very Low
  • Reported Version
  • Due in Version Version 3.1
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Anonymous Submitter - 2004-04-17
Last edited by Rani Hod - 2006-09-28

FS#2147 - Corrupt files using time split feature

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 0×0302; USB: positive; ATA:
0×200, 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

Closed by  Daniel Stenberg
2007-05-19 15:15
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.

Admin
Linus Nielsen Feltzing commented on 2004-06-04 12:06

Can you try the latest (2004-06-05) build and see if it
works better?

Anonymous Submitter commented on 2004-09-12 16:16

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

Jochen Bitzer commented on 2005-02-20 19:19

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 ;-)

David McIntyre commented on 2005-06-14 22:03

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.

Matthias Mohr (aka Massa) commented on 2006-04-27 14:16

Is this bug still present nowadays?
If nobody’s having this bug anymore and does report it here, I’ll close this task!

Jens Arnold commented on 2006-05-18 23:27

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.

Eddy commented on 2007-03-06 20:05

Is this still a problem with all the recording code updates recently?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing