Bug 135190

Summary: amarok doesn't play tracks till the end, clips last syllables (audiobooks) when last track in playlist
Product: [Applications] amarok Reporter: Janet <bugzilla>
Component: generalAssignee: Amarok Developers <amarok-bugs-dist>
Status: RESOLVED FIXED    
Severity: normal CC: andi3, aurel.w, bluelightning, cruff, mgolden, solstice.dhiver
Priority: NOR    
Version: 1.4.3   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: amarok eats end of soundfile - comparison of blank part at end of file, gap length and eaten part
Test music file, wma format

Description Janet 2006-10-06 13:13:25 UTC
Version:           1.4.3 (using KDE 3.5.4, Debian Package 4:3.5.4-3 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.17.9-slh-smp-1

When a spoken text (audiobook, podcast) is the last track in the playlist, about the last two syllables of this text get clipped. If another track follows the audiobook the last two syllables are pronounced fine. Tested it with "Der Zauberlehrling" von www.vorleser.net (http://www.phoneticsgroup.de/audio/goethe/goethe_zauberlehrling.mp3 - legal and free download) and other similar mp3s.
Comment 1 Alexandre Oliveira 2006-10-10 23:09:53 UTC
*** Bug 135418 has been marked as a duplicate of this bug. ***
Comment 2 munlinux 2006-10-15 10:57:44 UTC
Confirmed with 1.4.3., KDE 3.5.5.
Comment 3 Alexandre Oliveira 2006-10-28 00:45:26 UTC
*** Bug 135434 has been marked as a duplicate of this bug. ***
Comment 4 Alexandre Oliveira 2006-10-28 00:45:57 UTC
*** Bug 136118 has been marked as a duplicate of this bug. ***
Comment 5 Daniel Kao 2006-10-31 08:08:16 UTC
Problem still persists in 1.4.4, KDE 3.5.5
Comment 6 Alexandre Oliveira 2006-11-05 19:48:23 UTC
I can't reproduce this with current svn.
Comment 7 Andrew Gaydenko 2006-11-05 20:40:34 UTC
Alexandre,

Have tried current svn version after your message with cleaning build tree - via 'amarok-svn.sh -c'. The problem still exists.

Am ready to supply any additional info.
Comment 8 Tobias Knieper 2006-11-05 20:50:56 UTC
i tried to reproduce this quite a lot today but had no chance. do you have crossfading enabled? does disabling crossfading resolve the issue?
Comment 9 Andrew Gaydenko 2006-11-05 21:07:11 UTC
I don't use crossfading at all. 

Probably this additional info may be useful: when gap is set to about 3000 mS, last song last seconds are not eated. But to be most close to gapless playing back, I set gap to about 900 mS (still not "gapless", but this is another story).

(~x86 Gentoo, xine engine, FLAC files)
Comment 10 Tobias Knieper 2006-11-05 21:14:07 UTC
Hmm, i only have mp3 files, so this is maybe a flac related issue? The initial reporter points to a mp3 file, can you also reproduce it with the file mentioned there?
Comment 11 Andrew Gaydenko 2006-11-05 21:22:13 UTC
For me the issue doesn't take place with wav and mp3 files (have tried just now).
Comment 12 Janet 2006-11-06 03:39:04 UTC
I don't use flac, just mp3 and ogg. And it happens with both. I have set the gap between songs to 0 ms and don't use crossfading. It really seems to be the gap. When I set it to 800 ms it does not happen. But the gap time shouldn't affect the last file in the playlist, imho makes no sense because nothing follows.
Comment 13 mgolden 2006-11-06 06:12:30 UTC
When I reported this bug (here: http://bugs.kde.org/show_bug.cgi?id=135434 ) I noticed that it most definitely did not occur for mp3 and ogg files.  I only saw it happening for .au (and NeXT .snd files, which are essentially the same thing).  I have checked it with 1.4.4 (the latest Kubuntu package) and I think it is still happening.  I didn't try it for wav files.

I am using the xine engine, and don't have crossfading enabled.

Comment 14 Reuben Thomas 2006-11-06 15:02:09 UTC
I'm having this bug with only FLAC files. I have crossfading disabled with a 0ms gap between tracks.
Comment 15 Janet 2006-11-06 20:47:57 UTC
Maybe we should compare the sound files. My guess: it happens with every soundfile, independent of the format, that doesn't have "enough" space at the end but ends where the sound ends. And the smaller the gap is the more is cut from the sound. I have opened my "zauberlehrling.mp3" with audacity and with amarok. With amarok I tried several gap settings and noticed different endings. In audacity I listened to the file again and have marked the part that is cut by amarok.
Comment 16 Janet 2006-11-06 20:59:42 UTC
Created attachment 18444 [details]
amarok eats end of soundfile - comparison of blank part at end of file, gap length and eaten part

audacity screenshots: comparison of blank part at end of file, gap length and
eaten part

Tracks with more space at the end are cut too I guess - but you cannot hear it
because the part doesn't contain any sound.
Comment 17 Alexandre Oliveira 2006-11-08 16:03:06 UTC
Can someone send me a small file that i could use to test this? Most of my files have some silence in the end.
Comment 18 Andrew Gaydenko 2006-11-08 19:21:03 UTC
Alexandre,

Say, this one (~16MB)

http://gaydenko.com/tmp/01.flac

If it isn't sufficiently small, please, tell me what file size must be.
Comment 19 Mark Kretschmann 2006-11-08 19:56:04 UTC
My research has shown that this is clearly a xine bug. Could anyone try to compare with Kaffeine and other xine clients?
Comment 20 Andrew Gaydenko 2006-11-08 20:09:36 UTC
Mark,

Have tried just now the referenced track with kaffeine ("Kaffeine-Xine" engine). No problem.
Comment 21 Mark Kretschmann 2006-11-08 20:36:59 UTC
Thanks Andrew, this is interesting. I'm very keen on fixing this problem, and any help is welcome. Patches, code review, testing, etc.
Comment 22 mgolden 2006-11-12 00:32:07 UTC
I wonder if this bug reported over on the xine list is the same thing?

http://sourceforge.net/tracker/index.php?func=detail&aid=1480668&group_id=9655&atid=109655
Comment 23 Alexandre Oliveira 2006-12-23 20:43:35 UTC
*** Bug 138980 has been marked as a duplicate of this bug. ***
Comment 24 solsTiCe 2007-01-05 12:27:21 UTC
i use xine-lib 1.1.3 and amarok(using xine engine) svn 611973 cuts the last second of my mp3 podcast
while i can listen to that last second with xine-ui 0.99.4

i use no fade-in or out at the end of track but it work when i add a blank of more than 700ms 
when the track is the last one

Comment 25 Alexandre Oliveira 2007-01-05 12:30:38 UTC
*** Bug 133977 has been marked as a duplicate of this bug. ***
Comment 26 Mark Kretschmann 2007-01-07 14:11:46 UTC
Sorry, this is a xinelib bug. All xine based players, including the original xine-ui, exhibit the same behvavior. So we have to wait until it gets fixed upstream.
Comment 27 Mark Kretschmann 2007-01-07 14:12:37 UTC
*** Bug 139718 has been marked as a duplicate of this bug. ***
Comment 28 Andrew Gaydenko 2007-01-07 15:59:52 UTC
Mark,

Rather unsuspected way to resolve the issue :-) To be a pedant, let's try *all* xinelib clients, OK? For example, the issue doesn't take place with Kaffeine.

Please, reopen the issue.
Comment 29 Maximilian Kossick 2007-01-07 18:49:19 UTC
I agree with Andrew, both xine-ui and kaffeine do not have this problem.
Comment 30 Maximilian Kossick 2007-01-07 18:52:49 UTC
SVN commit 620899 by mkossick:

stops amarok from cutting of the last second or so of a track when sing the xine engine
TODO: make sure it behaves correctly when tracks are added/removed after the current track
CCBUG: 135190

 M  +17 -1     xine-engine.cpp  


--- trunk/extragear/multimedia/amarok/src/engine/xine/xine-engine.cpp #620898:620899
@@ -191,7 +191,7 @@
     if ( xine_check_version(1,1,1) && !(m_xfadeLength > 0) ) {
         // enable gapless playback
         debug() << "gapless playback enabled." << endl;
-        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 1 );
+        //xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 1 );
     }
 #endif
    return true;
@@ -259,6 +259,22 @@
       xine_post_wire( source, target );
       #endif
 
+      #ifdef XINE_PARAM_EARLY_FINISHED_EVENT
+      #ifdef XINE_PARAM_GAPLESS_SWITCH
+      if ( xine_check_version(1,1,1) && !(m_xfadeLength > 0) && Playlist::instance()->isTrackAfter() )
+      {
+        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 1 );
+        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT enabled" << endl;
+      }
+      else
+      {
+        //we don't want an early finish event if there is a track after the current one
+        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 0 );
+        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT disabled" << endl;
+      }
+      #endif
+      #endif
+
       return true;
    }
    else
Comment 31 Maximilian Kossick 2007-01-07 20:03:35 UTC
SVN commit 620921 by mkossick:

fixed problem where Amarok would not play the last second or so when using the xine engine
BUG: 135190

 M  +24 -15    engine/xine/xine-engine.cpp  
 M  +2 -0      engine/xine/xine-engine.h  
 M  +2 -0      enginecontroller.h  
 M  +2 -0      playlist.cpp  


--- trunk/extragear/multimedia/amarok/src/engine/xine/xine-engine.cpp #620920:620921
@@ -85,6 +85,7 @@
     #endif
     addPluginProperty("HasCDDA", "true"); // new property
     debug() << "hello" << endl;
+
 }
 
 XineEngine::~XineEngine()
@@ -259,21 +260,7 @@
       xine_post_wire( source, target );
       #endif
 
-      #ifdef XINE_PARAM_EARLY_FINISHED_EVENT
-      #ifdef XINE_PARAM_GAPLESS_SWITCH
-      if ( xine_check_version(1,1,1) && !(m_xfadeLength > 0) && Playlist::instance()->isTrackAfter() )
-      {
-        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 1 );
-        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT enabled" << endl;
-      }
-      else
-      {
-        //we don't want an early finish event if there is no track after the current one
-        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 0 );
-        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT disabled" << endl;
-      }
-      #endif
-      #endif
+      playlistChanged();
 
       return true;
    }
@@ -869,6 +856,28 @@
     }
 }
 
+//SLOT
+void
+XineEngine::playlistChanged()
+{
+    #ifdef XINE_PARAM_EARLY_FINISHED_EVENT
+    #ifdef XINE_PARAM_GAPLESS_SWITCH
+    if ( xine_check_version(1,1,1) && !(m_xfadeLength > 0) 
+         && m_url.isLocalFile() && Playlist::instance()->isTrackAfter() )
+    {
+        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 1 );
+        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT enabled" << endl;
+    }
+    else
+    {
+        //we don't want an early finish event if there is no track after the current one
+        xine_set_param(m_stream, XINE_PARAM_EARLY_FINISHED_EVENT, 0 );
+        debug() << "XINE_PARAM_EARLY_FINISHED_EVENT disabled" << endl;
+    }
+    #endif
+    #endif
+}
+
 static time_t last_error_time = 0; // hysteresis on xine errors
 static int    last_error = XINE_MSG_NO_ERROR;
 
--- trunk/extragear/multimedia/amarok/src/engine/xine/xine-engine.h #620920:620921
@@ -59,6 +59,8 @@
     virtual void customEvent( QCustomEvent* );
     virtual void timerEvent( QTimerEvent* );
 
+    virtual void playlistChanged();
+
     Engine::SimpleMetaBundle fetchMetaData() const;
 
     bool makeNewStream();
--- trunk/extragear/multimedia/amarok/src/enginecontroller.h #620920:620921
@@ -91,6 +91,8 @@
 
     void mute();
 
+    void playlistChanged() { m_engine->playlistChanged(); }
+
     void slotStreamMetaData( const MetaBundle &bundle );
     void currentTrackMetaDataChanged( const MetaBundle& bundle ) { m_bundle = bundle; newMetaDataNotify( bundle, false /* no track change */ ); }
 
--- trunk/extragear/multimedia/amarok/src/playlist.cpp #620920:620921
@@ -219,7 +219,9 @@
     connect( ec, SIGNAL(orderNext( const bool )),     SLOT(playNextTrack( const bool )) );
     connect( ec, SIGNAL(orderCurrent()),  SLOT(playCurrentTrack()) );
 
+    connect( this, SIGNAL( itemCountChanged( int, int, int, int, int, int ) ), ec, SLOT( playlistChanged() ) );
 
+
     setShowSortIndicator( true );
     setDropVisualizer( false );   //we handle the drawing for ourselves
     setDropVisualizerWidth( 3 );
Comment 32 Andrew Gaydenko 2007-01-08 02:51:02 UTC
Maximilian,

Have tried last SVN commits (up to 620921) - short tests show the issue is gone. Clean rebuild was needed.

Thanks!!
Comment 33 Tobias Niwi 2007-02-07 22:24:59 UTC
I still have this problem at least with one mp3-file (http://ondemand-mp3.dradio.de/podcast/2007/01/01/dlf_200701010930.mp3 sporadically. The last second often gets clipped when the file is last in play list. Audacity plays the same file correctly. I use the latest version of Amarok (1.4.5) and xinelib 1.1.4-0 (packed by Packman for Suse 10.1). Taglib shows the right length.

Please reopen this bug report.
Comment 34 Mark Kretschmann 2007-02-07 22:37:42 UTC
Won't reopen. Problem is intrisic to xinelib.
Comment 35 Tobias Niwi 2007-02-07 23:12:59 UTC
Resolution should then be changed to 'wontfix' or 'invalid' since it is not 'fixed' yet.

Since it was claimed in this bug report that the bug got fixed (it is even mentioned at http://amarok.kde.org/content/view/10/66/) i wonder how it is possible that it is at the same time an intrisic problem/bug of xinelib. I also wonder why the problem does not exist in Kaffeine which also uses xinelib (see also X29).

Is there already a bug report for xinelib written?
Comment 36 Mark Kretschmann 2007-02-07 23:32:19 UTC
On Wednesday 07 February 2007 23:12, Tobias Niwi wrote:
> Since it was claimed in this bug report that the bug got fixed (it is even
> mentioned at http://amarok.kde.org/content/view/10/66/) i wonder how it is
> possible that it is at the same time an intrisic problem/bug of xinelib. I
> also wonder why the problem does not exist in Kaffeine which also uses
> xinelib (see also X29).


We've done extensive tests with several xine based players, including xine-ui. 
xinelib generally cuts off the last second or so from any file. It's clearly 
audible with short spoken language samples.

> Is there already a bug report for xinelib written?


No idea.
Comment 37 Tobias Niwi 2007-02-08 09:09:29 UTC
Mark Kretschmann wrote:
> We've done extensive tests with several xine based players, including xine-ui. 
> xinelib generally cuts off the last second or so from any file. It's clearly 
> audible with short spoken language samples.
   
I tried the reported file with Kaffeine several times without getting
the reported error. Even in Amarok the reported bug is only occuring when the reported
file is at the end(!) of the playlist. If another track follows
everything works as it should. This seems to indicate that xinelib does
not "generally cuts off the last second or so from any file" but only in
(some or all) cases when the file is at the end of Amaroks playlist.
Wouldn't it be possible for Amarok to treat the last track of the
playlist the same way as tracks in the middle of the playlist are
treated in respect to the xine-engine?

Comment 38 Tobias Niwi 2007-02-08 09:54:02 UTC
I have written a bug report in xine bug tracker: https://sourceforge.net/tracker/index.php?func=detail&aid=1654924&group_id=9655&atid=109655
Comment 39 Barry Klein 2007-03-30 06:00:51 UTC
Created attachment 20128 [details]
Test music file, wma format
Comment 40 Barry Klein 2007-03-30 06:02:13 UTC
I have a similar problem with a .wma file (dbanjo3.wma - attached). Amarok shows the length as 2:42, but only plays 2:31 when it is the last in the playlist. 

Changing the "No crossfading" gap to 10s (10,000ms) allows the file to play to the 2:41 point (sound is heard during the 'gap' time!!). The analyser display stops at 2:31!

xine plays the entire file except for the last second (i.e. to 2:41).

I suggest that there is a bug in amarok as well as one in xine.

Kaffeine reports the length as 2:41, stops counting at 2:31, but keeps playing for a few seconds more.
Comment 41 Modestas Vainius 2007-12-26 03:01:12 UTC
The wma referred in comment #40 plays fine up until the end with amarok 1.4.8 / xine 1.1.8 with or without crossfading and/or gap. The issue with analizer stopping at 2:31 is still there if the track is not the last one in playlist, however amarok CONTINUES playing the track. I've not noticed any issues at all with the track being the last one in the playlist.
Comment 42 Rena Kunisaki 2008-10-06 03:27:19 UTC
I have the same problem with version 1.4.9.1 (KDE 3.5.9), with FLAC, MP3 and OGG files. When the song is the last in the playlist or I set "Stop after this track", the last few seconds - in some cases as much as 30 seconds - get cut off. I have crossfading off, gap 0ms.
Comment 43 Andreas E 2012-10-18 13:28:34 UTC
Resolved Fixed?

Hah. Sorry for beating up a seemingly dead horse, but I can reproduce this problem on Amarok 2.5.0 using phonon-backend-vlc. This means it doesn't even have anything to do with xine (or not anymore) because xine is now deprecated and to my knowledge even no longer supported in Amarok.
I don't assume 2.6.0 would make a significant change, otherwise there would have been something in the changelog about it.

Mplayer plays the last syllable perfectly, hence I know that my mp3s are ok.
Comment 44 Myriam Schweingruber 2012-10-19 08:00:54 UTC
(In reply to comment #43)
> Resolved Fixed?
> 
> Hah. Sorry for beating up a seemingly dead horse, but I can reproduce this
> problem on Amarok 2.5.0 using phonon-backend-vlc. This means it doesn't even
> have anything to do with xine (or not anymore) because xine is now
> deprecated and to my knowledge even no longer supported in Amarok.
> I don't assume 2.6.0 would make a significant change, otherwise there would
> have been something in the changelog about it.
> 
> Mplayer plays the last syllable perfectly, hence I know that my mp3s are ok.

Besides the fact that you are commenting on a 1.x bug instead of a 2,.x one:
The clipping is the phonon-backend-gstreamer causing the problem, use the phonon-backend-vlc instead.

Definitely works here with Amarok 2.6 and 2.6-git with the phonon -backend-vlc 0.6.0
Comment 45 Janet 2012-10-19 10:59:17 UTC
(In reply to comment #44)

> The clipping is the phonon-backend-gstreamer causing the problem, use the
> phonon-backend-vlc instead.
> 
> Definitely works here with Amarok 2.6 and 2.6-git with the phonon
> -backend-vlc 0.6.0

As he said he already uses the vlc backend. But i can confirm that it works with Amarok 2.6 - with the gstreamer-backend.