• Registered: 2007-07-19
  • Posts: 77

Topic: Quirky behavior near end of file

This is a little tricky to explain, so I'll outline this as a series of steps:

1) Frequently, if I position the slider within 2-3 seconds of the end of a file, the slider will grey out and "freeze", and no music will play.  I can reproduce this bug repeatedly if I reposition the slider two or three times within the last five seconds of a file -- on the second or third repositioning, the music stops, as if Cog were paused.

1a) However, the play/pause button still displays a pause symbol, indicating that Cog believes itself to still be playing (at least from a UI point of view).

2) If I hit the pause button, it switches to the triangular play icon, while remaining as if paused...

3) ...and if I hit the button again, to resume playback, Cog immediately skips to the next track in my playlist.  If I'm at the end of the playlist, Cog just stops, with a greyed-out slider (just as if I'd played the song through to its end).

Crucial point that raises this to the status of a full-blown bug:  during Steps 1a or 2, I can reposition the slider anywhere in the track.  In other words, having gotten Cog to "jam" near the end, I can move the slider anywhere I want, and it appears that playback ought to resume from that point.

But it doesn't change a thing:  Cog won't play any audio until I go through a pause/unpause cycle (which makes Cog skip to the next track), or double-click on some track in the playlist (which makes Cog play that file from the beginning). 

Thus, it's more than a bit confusing from a UI perspective:  you're checking the end of a file and moving the slider, and suddenly Cog stops; you then move the slider back earlier in the track and try to resume playback, and Cog either skips to the next track, or stops dead.

If I had to guess, it almost seems as if something in the last few seconds of the track is triggering a Cog process that doesn't want to be interrupted -- or, at least, that doesn't want to be asked to "back up" within the same track.  Maybe there's a bug in the gapless playback code?

This may seem like a minor point, but I use Cog all the time to preview tracks I'm going to be burning to CD, and often I'll check the end of a track repeatedly to listen for artifacts of various kinds.

Oh, and:  Powerbook G4, Cog 0.06 r516, OS X 10.4.8, plenty of RAM, etc.

Last edited by goldenband (2007-10-04 21:17:29)

  • Registered: 2007-07-08
  • Posts: 790

Re: Quirky behavior near end of file

Could you try r521 and tell me if you experience this problem or similar problems? This is likely caused by the gapless playback. Once Cog finishes reading a file, it closes it, and goes on to the next one. What is happening here is that Cog has already moved on to the next file by the time you seek, so things get weird. I don't know if this will be fixed for 0.07 since it requires quite a few changes, but it definitely needs fixing.

This is actually related to a problem with cue-sheets I was thinking about yesterday, where if the next song is the same file and the next track, it should just keep on playing and not open a new decoder. Otherwise, it would have to open/seek, which may not be perfect (or gapless) due to seektables and whatnot. Keeping the old decoder around is the tricky part, and I haven't quite worked out how to do so. I think initially it will use the open/seek method, just so something works, but it definitely should be corrected sooner before later.

  • Registered: 2007-07-19
  • Posts: 77

Re: Quirky behavior near end of file

I just tried r521, and the behavior is intriguingly different.  When I do the things that would normally trigger r516 to stop, r521 keeps playing.  However, the slider then becomes essentially nonfunctional until the next song begins:  during those last five seconds of the song, I can put the slider wherever I want, and it doesn't change a thing.  I can even pause Cog, move the slider, and hit play again;  doesn't matter -- after Cog plays the audio from the last few seconds of the track, it goes to the next one.

Still, this is definitely something of an improvement -- far better for Cog to keep playing to the end of the track, which makes more intuitive sense to the average user, than to stop dead, right?  I wouldn't worry too much about getting this fixed in time for 0.07, though it'd be nice to get it fixed eventually.

Hmmm, on the other hand, I did some more testing and this now seems to happen anywhere within the last TEN seconds of a track, rather than five seconds.  Odd.

About the cue sheet issue, is this like how certain hardware CD players will manually reseek each individual track when you program them to play (say) tracks 1, 2, 3, and 5?  When you're listening to continuous material, this creates an annoying gap as it reseeks, and I'm always pleased when I use a CD player that's smart enough to know "OK, track 2 comes right after track 1, I can just let it play through without reseeking."  Can you use a simple mathematical test like that, or is it more involved?

Last edited by goldenband (2007-10-05 08:57:00)

  • Registered: 2007-07-08
  • Posts: 790

Re: Quirky behavior near end of file