you are probably right in what you say, but for me personally it's just
too much effort to implement all this. If there are volunteers to
attempt this, and the result appears to be stable enough with a
sufficient amount of time saving (how often do you update all the tags
in your collection?) we can consider adding this to gtkpod.
Norman Ramsey wrote:
> Last night I tried to update metadata and eliminate duplicate iPod files
> by clicking 'update track(s) from file' on my entire iPod.
> This took my machine out for half an hour. One of the things I
> noticed was that if the metadata on a file changes, gtkpod appears to
> copy the *entire* new file to the iPod. As we have just been
> discussing, this operation is going to cause at least a 10x slowdown
> (probably more since the iPod hard drive can deliver/accept at most 10MB/s).
> An obvious and valuable thing to do would be for the iTunesdb.ext to
> store the following:
> 1. Start and end location of music (as opposed to metadata)
> 2. Hash of that section of the file
> Then when doing an update from hard drive, the procedure would be as
> 1. Read any files that have changed
> 2. Find start and end of music
> 3. Hash all of music (it's free, remember, since you have to read
> the file anyway)
> 4. If only metadata and not music has changed---in particular, if
> the *position* of the music has not changed, rebuild file on iPod
> using new metadata and existing music.
> I seem to recall reading that ID3v2 is designed to allow you to update
> the metadata without moving the mp3 frames that carry the audio
> payload, but a quick perusal of id3.org didn't confirm one way or
> If the music moves, I can't see any way to avoid transferring the bits
> to the iPod. (Too bad we can't put an rsync server on the iPod; this
> would solve the whole problem in a snap.)