*** Bug 135418 has been marked as a duplicate of this bug. ***

Confirmed with 1.4.3., KDE 3.5.5.

*** Bug 135434 has been marked as a duplicate of this bug. ***

*** Bug 136118 has been marked as a duplicate of this bug. ***

Problem still persists in 1.4.4, KDE 3.5.5

I can't reproduce this with current svn.

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.

i tried to reproduce this quite a lot today but had no chance. do you have crossfading enabled? does disabling crossfading resolve the issue?

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)

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?

For me the issue doesn't take place with wav and mp3 files (have tried just now).

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.

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.

I'm having this bug with only FLAC files. I have crossfading disabled with a 0ms gap between tracks.

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.

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.

Can someone send me a small file that i could use to test this? Most of my files have some silence in the end.

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.

My research has shown that this is clearly a xine bug. Could anyone try to compare with Kaffeine and other xine clients?

Mark,

Have tried just now the referenced track with kaffeine ("Kaffeine-Xine" engine). No problem.

Thanks Andrew, this is interesting. I'm very keen on fixing this problem, and any help is welcome. Patches, code review, testing, etc.

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

*** Bug 138980 has been marked as a duplicate of this bug. ***

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

*** Bug 133977 has been marked as a duplicate of this bug. ***

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.

*** Bug 139718 has been marked as a duplicate of this bug. ***

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.

I agree with Andrew, both xine-ui and kaffeine do not have this problem.

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

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 );

Maximilian,

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

Thanks!!

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.

Won't reopen. Problem is intrisic to xinelib.

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?

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.

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?

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

Created attachment 20128 [details]
Test music file, wma format

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.

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.

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.

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.

(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

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