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

[yapper]

I've noticed that Rockbox pauses playback while a fast-forward or rewind is in progress. Was a specific decision made to halt playback during these actions, e.g. to mimic the tone arm of a record player being lifted and moved further on in a track? ?
Personally, I prefer to have the music playing during the time FFWD or REW is active, and then hop to playing from the newly selected position once FFWD or REW is released, rather than have silence.

[bluebrother]

it's not paused, it's simply no audible seeking. And the reason is simply: nobody implemented audible seeking and most people prefer seeking being accurate instead of audible. Feel free to step in and code it ...

[yapper]

If by 'audible seeking' you mean hearing the seek (fast audio) in realtime, that wasn't what I meant. Rather I was meaning that regular x1 speed audio output would be preferable (to me) than silence while the new playback position was being selected.

I'm not a coder, but my choice of the term 'paused' was based on looking at the ffwd_rew routine in gwps-common.c, where this check seems to be causing audible output to cease as ffwd or rew is selected:

Code: [Select]

                        if (!wps_state.paused) 
#if (CONFIG_CODEC == SWCODEC)
                            audio_pre_ff_rewind();
#else
                            audio_pause();
#endif

and a very crude hack of removing the ! allows (regular x1) playback to continue while seeking is in progress when playing mp3s on my 2nd Gen iPod (I admit I was probably very lucky that the SWCODEC clause didn't kick in, but as I've already confessed, coding isn't something I do well).

[Llorean]

I think most people, especially blind users, would like some form of audible feedback while seeking, even if by "audible" it means "silence as opposed to sound." I've often performed seeking blind while trying to approximate where I was in an audiobook whose position I lost while keeping my eyes on the road, and find it helpful to hear exactly when the seek started, for example.

[Mikerman]

I wasn't aware, as noted above, that having the audio play (at a speeded up, sampling rate) while seeking would be "inaccurate."  This is one of those absent features that always has seemed odd to me (coming from iRiver players that have the feature)--it seems fairly standard to me, for some reason (imagine video seeking without images).

[Llorean]

Rockbox seeks much quicker than the iRiver firmware.

In the time it takes you to hear the 1/2 second of audio, either the seeking needs to stop while it's playing so that you can listen to that part of the audio, or your seek may have moved 4 or 5 minutes on (in very long files, which are the sort you tend to need seeking for).

If you want to hear the part of the audio at a given point, why not seek, then release, then seek, then release?

[yapper]

I can see that audio books might be a special case, but my comments were based on music playback.

Some of the OFs implement seek in the way I described so it's not just me (or is it?). It also seems a fairly fundamental choice to force on users, given so many other actions are customisable in Rockbox.   Mmmmm  add more options to the Settings menus  

[Llorean]

1) Option bloat is bad, especially since it includes code bloat and there are benefits to keeping the binary size slim, and the code easy for people to use (not that it is necessarily, especially in playback).

2) How often do you need to seek in a 3 minute file? I would imagine the majority of cases that seeking is used are in longer files.

Even then, in any file you're perfectly capable of releasing the seek button to hear where you are before resuming, and in ANY file, playing back parts of the file while seeking would either result in inaccuracy, or very, very slow seeking relative to what can be done now.

[yapper]

My comment about more options was tongue-in-cheek

A quick test on seek times on a 90 min mp3 with/without 1x playback during the seek shows very comparable times (approx 20 secs on a 2G iPod). I can't comment on accuracy losses.

[Mikerman]

In response to some of the above, audible seeking is extremely helpful in studying music and foreign languages, which often involves just-played portions of a file.  I would not consider audible seeking as bloat.  Again, I would compare it to VCD/DVD playback with and without a picture.

[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.