I've run into a weird problem where I can't play some of my older OGG files (from maybe 3-4 years ago) that I ripped at 160kbps VBR.  (Unfortunately, the CDs in question were stolen so I can't easily re-rip them.)

Audacious and XMMS play the files, I can load them into Audacity, I can even convert them with SOX (and Amarok will then play the MP3 files), but Amarok won't play them.  It just passes over them without playing: the playlist advances to the next song, the OSD displays the data for the OGG file for about one second then skips to the next song.  When the next song starts it usually has a short "skip" at the start of the music.  On the AMD machine it plays a second of the next song after the problem-OGG file then starts it over, almost as if the first few seconds were what it thought the problem-OGG file were.  Amarok also "scores" the problem-OGG file as if it had been fully played out.  I also note that the CPU usage goes high for a longer period than a normal song-change.

I can't figure it out.  I've tried it on two computers -- one an Athlon64 the other a P4 -- both the same, so it's not the Vorbis library or something like that.  (I'm running Gentoo stage 1 builds on both machines.)

The command-line output looks like this:

amarok: BEGIN: void EngineController::play(const MetaBundle&, uint)
amarok:  [controller] Loading URL: file:///mnt/AudioServer/albums/M/Metheny,%20Pat/Pat%20Metheny%20Group%20(1978)/01-San%20Lorenzo.ogg
amarok: BEGIN: virtual bool XineEngine::load(const KURL&, bool)
amarok:    [xine-engine] Before xine_open() *****
amarok:    [xine-engine] After xine_open() *****
amarok: END__: virtual bool XineEngine::load(const KURL&, bool) - Took 0.8s
amarok: BEGIN: virtual bool XineEngine::play(uint)
amarok: BEGIN: void EngineSubject::stateChangedNotify(Engine::State)
amarok:      [virtual void amaroK::StatusBar::engineStateChanged(Engine::State, Engine::State)] Line: 137
amarok: BEGIN: virtual void ContextBrowser::engineStateChanged(Engine::State, Engine::State)
amarok: END__: virtual void ContextBrowser::engineStateChanged(Engine::State, Engine::State) - Took 0.0005s
amarok: END__: void EngineSubject::stateChangedNotify(Engine::State) - Took 0.0094s
amarok: END__: virtual bool XineEngine::play(uint) - Took 0.01s
amarok: BEGIN: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool)
amarok:    [Moodbar] Resetting moodbar: /mnt/AudioServer/albums/M/Metheny, Pat/Pat Metheny Group (1978)/01-San Lorenzo.ogg
amarok: BEGIN: virtual void ThreadWeaver::Thread::run()
amarok: END__: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) - Took 0.36s
amarok: END__: void EngineController::play(const MetaBundle&, uint) - Took 1.2s
amarok: BEGIN: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint)
amarok: END__: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint) - Took 0.21s
amarok: END__: virtual void ThreadWeaver::Thread::run() - Took 0.71s
amarok: [ThreadWeaver] Job completed: CurrentTrackJob. Jobs pending: 0
amarok: [xine-engine] XINE_EVENT_UI_PLAYBACK_FINISHED
amarok: BEGIN: void EngineController::play(const MetaBundle&, uint)
amarok:  [controller] Loading URL: file:///mnt/AudioServer/albums/A/Arie,%20India/Acoustic%20Soul%20(2001)/03-Promises.ogg
amarok:  [CollectionDB] track ended: file:///mnt/AudioServer/albums/M/Metheny,%20Pat/Pat%20Metheny%20Group%20(1978)/01-San%20Lorenzo.ogg
a

The only thing I can figure is that the Vorbis library changed sometime in the past few years and there's a certain something-or-other that is no longer common which Amarok isn't handling properly but the other media players are.  From the output, it looks like Amarok thinks everything went normally (even though it tells me the song is 10:16 but thinks it played it in about one second flat).

Any of the devs interested in having a look at this one?

At first check which Ogg Vorbis version these files are:

Code: Select all

ogginfo problem.ogg

It says:

Version: 0
Vendor: Xiphophorus libVorbis I 20010615 (1.0 rc1)

I also have some 192kbps files of the same version that won't play, so it isn't specific to the bit-rate.