Seek Tool data not retained for some tracks

I ripped The Wall without VBR tags, as required by lame --nogap at the time. This means the tracks have the wrong length in the player.

The seek tool seems to remember its maps for those tracks that under-report their time (truncated to the believed time, I think), but forgets all those for tracks that appear longer than they are.

As a wishlist, WIBNI the correct length (even better a full VBR header) was calculated as part of the seek tool mapping, and applied to the database at the next sync?

Toby has recently done some work to make the Seek Tool more reliable in the face of bogus track durations. Don't know if it'll fix your problems, though.

As to your wishlist item: Tricky. The disks are mounted read-only, and there's not enough space in persistent storage to keep VBR headers for (potentially) every track on the player.

The correct solution would be to fix the VBR headers up in-place, on the empeg, when the disks were mounted read-write (i.e. during a sync).

Hmmm, maybe we can actually do this? Probably won't make it into v2.0, though.

Does --nogap still work if you have fixed up the VBR headers with a repair tool such as VBRFix or MP3Trim?

In reply to:

---

Does --nogap still work if you have fixed up the VBR headers with a repair tool such as VBRFix or MP3Trim?

---

Haven't tried that yet (I'm not sure whether I still have them on my workstation, and I'm too lazy to search out and build tools that aren't in Debian - though if you (or anyone else) knows of a suitable tool in woody, I'd love to hear of it).

In reply to:

---

The disks are mounted read-only, and there's not enough space in persistent storage to keep VBR headers for (potentially) every track on the player.

---

I assumed there'd be space wherever the seek maps go...

It might be sufficient to store a mark for each track that needs attention, and an ability to fix them at sync time (possibly not by default, though, as it would be time-consuming....)
Fixing the total time is more important than the VBR headers, though.

The seek map for each track is very small. I'm not sure that a VBR header is that small.

The Seek Tool will only save the profile data for a track if the tagged duration of a track is less than or equal to the actual playback duration of the track.

Detecting that a track has a duration tag that is shorter than the actual track is very easy (becuase you get timecodes greater than the duration would suggest).

Detecting that a track has a duration tag that is too long is actually quite involved, because from the Seek Tool's point of view it is not apparent whether you just skipped over the end of the track, or whether the end of the track was reached but that the tagged duration is wrong.

Unfortunately the reason for the Seek Tool not storing profile data for some tracks is that they have duration tags that say the track is longer than it actually is, and so there is no easy way of making it detect this and correct as appropriate. The simple answer (which would stop all the posts about partial profiles appearing) would be to make the seek tool store the profile no matter how much of it has been completed.

Of course, the correct answer is to make sure that your player has correct duration tags, but there is no easy way to do this.