On Wed, May 28, 2008 at 9:39 PM, Jorg Schuler <jorg.schuler@...> wrote:
> > In that case I'm afraid I'm all out of ideas, besides the obvious of
> > adding
> > tag-specific hashing or hashing a large chunk of the file (if not all of
> > it).
> gtkpod takes the filelength and a chunk of data from the beginning to
> determine the hash. The size of the hunk was determined to be as small as
> possible but large enough to avoid complaints from "normal" users. The
> reason why we don't hash the whole file is of course obvious: time.
Unless the drive is very fragmented, you can probably read 256k from a hard
disk (or even megabytes in some drives) in practically the same time you
read 16k. Unfortunately I don't know how the iPod's hard drive or the solid
state drive versions behave in this case.
Taking 16k from the beginning and 8k from the end + filesize might catch
> most problems. I'm not sure how time-intensive it is to get the 8k from the
> end of a long file. Any ideas?
Reading 8k from the end can be probably done with one extra disk seek in one
read, so it won't be expensive at all in this scenario. However, if the most
typical change is modifications to the tags, and no tags are added to the
end, then this is not going to give you any improvement. Furthermore, since
you probably don't need any extra disk seeks when reading a continuous
block, it should be cheaper to read 128k or more from the beginning than
16+16 from two parts of the file. Again, this applies to hard disks in
general and I don't know how the iPod (either solid state or hard drive)
behaves in particular.