Play pauses during FFWD or REW .... should it?

[dip]

And that means that blind people will get no audible feedback that they're seeking, I brought that up in response to your original subject. It means the only feedback to a seek beginning is visual.

Wouldn't that be an argument for playing a fast forward/rewind sound (not the 1x normal sound as originally requested in this thread). At the moment there is no audible feedback at all (since playback is paused) during fast forward or rewind which means that blind people can not recognize if the pressed the pause or stop button instead of the fast forward or rewing button in error.

Many mp3-players (e.g. the original iPod firmware) and CD players use such a fast forward/rewind sound and in my opinion even if it is a kind of chopped sound it helps a lot for finding a desired position within the song.

[Llorean]

The point was that some devices (Gigabeat for example) give very little physical feedback when you press the seek button, so you may not know if you've depressed it.

I think it's quite unlikely that they'll press the wrong button altogether.

But I still don't see how implementing a seek mode that is *exactly* like pressing and releasing seek is a good use of binary size since I think if you can seek at all, you're quite physically capable of pressing and releasing it.

[pabouk]

I agree that there is an issue with speed and audible seeking.  But I can see an option in which one could choose whether or not to have audible seeking on or not, and then coordinate the speed of seeking accordingly, as currently is possible.

Mikerman, I think that you are still talking about a different topic (fast playing audio during seeking - audible position feedback). BTW I fully support addition of this feature. It was requested many times and I think that a large part of the core developers agree with addition of this function. The only problem probably is that the implementation is difficult and no one started working on it.

To oppose Llorean's arguments: This feature is implemented in many players and it works well. I know that the other players/firmwares do not seek so fast but the audible feedback could be more exact during the slow seeking and coarse during in the fast stages. I think that it could be implemented as a combination of fast playback (like the current pitch control feature) - as fast as the CPU will be able to decode - with omitting parts of the audio (for example play every second 20ms chunk) as it is done on CD players.

I'm not blind so I can't comment on how necessary audible feedback is. However it seems to me that since the seek doesn't start spontaneously, it's not an unexpected event like, say, a very low battery warning. It's triggered by the user depressing a button.

I think that we can hardly imagine how it is - to be blind. Just try it yourself - close your eyes and use your player. We can see the optical feedback on the display but when you press a button and you do not know whether the press was registered is very uncomfortable. I think that verifying whether the seeking is happening by stopping it as you suggested is unacceptable. BTW I think that continuing playback during seeking is really not necessary.

[dip]

@yapper
What device do you have? For iPods there is a patch (FS#7762) available which implements a scrub mode like the original iPod firmware has. If you set the scrub mode timeout to a value different from "off" than normal (1x) playback will continue during srcubbing until you stop scrubbing for about 1 second after which playback will start at the new position.

I guess this would completely satisfy your desire. Note, that you need a further patch (FS#7555 double click feature) to start scrub mode with a double click of the select button.

I hope this helps

[yapper]

@dip:

Thanks - I'm aware of the iPod patches you refer to (I can see Llorean twitching at the mention of double-click   ).

Re blind users ... does the voice feature allow feedback to be provided on button actions?

[Llorean]

I've thought of another problem with audible seeking: Disk access. On longer than buffer files, you'll have to force a rebuffer long before the user stops the seek, or will have to read from the disk for the audible samples. As well, seeking backwards will, I believe, require an immediate rebuffer or disk seek and possibly multiple reads as well depending on how you choose to handle it.