seanadams wrote: > This is about the same as complaining that you can't "scratch" on a CD > player the same way you could on last century's phonograph...
Hi Sean, Thanks for your great summary of how ff/rw work differently between CD and tape deck. It is clear that the designers of both of those transports produced the best ff/rw feature possible within the technical constraints of the transport technology. > it's helpful to understand some details of how FF/RW > scanning works on a CD player, since that is the behavior we want to > emulate. It seems that you are making the problem harder than it needs to be. ff/rw on a slim device doesnt have to work *the same way* as a CD player. It doesnt have to "blurp". Nor does it need to sound like chipmunks. It was never the case that some user focus group decided it would be desirable a CD player to play "blurps" while fast forwarding - some engineer did it that way because it was EASY. Yes, this relates your final point on code complexity. I agree this should be the driving factor here. So, is there a *different* method of handling the ff/rw use case which is technically easier? I can make some guesses..... > Every format has different size frames, and many > can even be variable in size. For some formats it is not possible to > know how far to look ahead in order to advance by some amount of time. > You either have to guesstimate and then resync Would it really be a showstopper to guesstimate, without the resync? It was never a problem that the advance speed of FF on a tape varied with how much tape was already spooled. > or you have to process every frame in between. For the rewind case, every frame would already have been processed anyway. > Currently our transcoding > capability does not support seeking of any kind within a track Maybe slimserver could spool the output of the transcoding process to disk, and seek within that? Would it be OK for seeking to have a granularity of a few seconds (or a few frames)? > In order to quickly move to a different point in > the stream, you would need to implement a very sophisticated buffering > scheme, So we need a user interface for choosing the ff/rw restart point which sidesteps this buffering problem. SongScanner suggests one solution. _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/audiophiles
