From: Philipp Pertermann <Philipp.Pertermann_at_web.de>
Date: Thu, 09 May 2002 01:24:01 +0200

Paul Suade wrote:
> How to move byte in cluster chain ?
> Bytes always be copied at a lesser address

Yes, but shifting all the data still means that each single bit must be
touched.

> Yes, maybe we can use the truncated part as the cluster chain for the new file,
> if we copy the pre-truncated cluster and fill the gap with a dummy mp3 chunk
> (?) for the start cluster of the new file and link it with the post-truncated
> clusters without change to form a cluster chain. But I'm not sure if it is
> feasable and recommended.

Advantages:
- can be performed in constant time / battery
- can be performed in constant memory (hd) usage

Disadvantages
- frequent file splitting will aggregate dummy mp3 chunks
   -> some little bit of wasted hd space
- might produce 'ugly' mp3 files

My opinion:
When I've recorded a 5 hour live show with the JBR that contains
serveral pauses (eg. bands change) I might want to split the large file
and get rid of the useless pauses. If that implies that almost all of
the data has to be copied / shifted on disc, the JBR might be busy for
quite a while. And than the batteries _will_ be drained - of course
during operation - the splitting action fails and all data will be
trashed. Besides I'd never have enough free space on the hd anyway.

Considering the portable use of the JBR I'd rather move hell to avoid
copying / shifting mass data - even at the cost of 'ugly' mp3 files. And
if someone can produce SH1 code to create 'ugly' mp3 files he probably
can write a Linux/Windows/Mac application that identifies and cleans
those files, easily.

I just hope that this soap bubble of dummy mp3 chumks doesn't deflate
like the dream of a file system that doesn't force files to start at
cluster boundaries.

Phil
Received on 2002-05-09