Support and General Use > Audio Playback, Database and Playlists
Play pauses during FFWD or REW .... should it?
Llorean:
Mikerman: DVD seeking with picture is different though. If you decode a DVD at 100x normal speed, you can still recognize where in the movie you are *now* (or within 100 frames or so), and stop. If you decode audio at 100x normal speed, it's not necessarily recognizable. If you decode it at 1x speed, while moving at 100x, then when 1 second as passed of audio, you're a minute and a half further in the seek.
yapper: What sort of 1x playback during the seek? I only said it would slow a seek if it stopped seeking during the playback rather than continuing onward.
Seriously, why is it hard to release seek, see where you are, then resume seeking? That means 0 code size increase (non-bloat or bloat, it doesn't matter) and is functionally equivalent to the audible method that would allow the most accuracy for seeking.
yapper:
This thread seems to have got a bit off track from my original post (although the discussion has raised points I hadn't considered).
My 'concern' was that when playing a long music track (in my case a full concert), and choosing to seek forward, regular x1 audio output stopped while the seek was in progress. My (personal) preference would be to have the track continue to play at regular 1x speed, until the seek action is ended (i.e. release of FFWD).
The test I did was using the very crude hack I posted earlier to prevent playback ceasing.
Llorean:
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.
If you're going to a new place in the audio, why exactly do you need to continue hearing the current place anyway?
As for "adding a choice", this just means a larger binary for a function that's not actually functionally useful (you're seeking away from the point as it is).
Mikerman:
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.
Right now, in fact, I do just seek and play and seek and play (having no choice otherwise). And it just feels like a kludge to me, being a trial-and-error thing rather than a developed and completed feature.
Personally, I wouldn't see audible seeking as bloat, but rather as a true feature. Not to be a lemming, but, isn't it a norm in the industry? (I don't know--I've only had my iRiver iHP-140, which has it.) But hey, it ain't gonna happen regardless, and so time is better spent elsewhere.
yapper:
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. To verify if the seek is actually happening, a blind user can release the button. In reality, the preferences of blind users likely vary as wildly as the preferences of sighted users - there will be no single perfect solution.
As for why I like the playback to continue while seeking - if I absolutely hate the bit of music that is currently playing, I'll hit pause, then seek. Otherwise (99% of the time) I'll just seek.
In fact originally I was wondering why the audio didn't fade instead of halting abruptly (in accordance with my 'Fade on Stop/Pause' setting), until I realised that I didn't even know why it had to stop in the first place.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version