Version: (using KDE KDE 3.5.2) Installed from: Ubuntu Packages This can somehow be considered as a bug, too. The problem appears whenever you got the cue file that doesn't match the filename of the mp3 file it's meant to be used with. Amarok, in such situation, won't 'see' this cue file at all, and make use of it. Usually, such situation happens for a "scene releases", where files are named like 00-(...).cue and 01-(...).mp3 etc. The solution is to for Amarok to take a look inside the cue file and see if the FILE field is present and if so, to check if the file it indicates exist in the current subdirectory. If it does, Amarok can use it just like it does now.
One more note: search for the file indicated with FILE should obviously be case insansitive.
*** Bug 128047 has been marked as a duplicate of this bug. ***
I quite Often come accross the situation when cue filename is different from the coresponding mp3 filename. Is it just me beeing so unlucky?
Created attachment 19133 [details] Provides the fix for this feature request/bug Hope it's good, that's my first OSS contribution ever :-)
SVN commit 620635 by aumuell: support for cue files in same directory as audio file but with a different base name - thanks to Dawid Wrobel <dawid@klej.net>for the patch BUG: 128046 M +2 -0 ChangeLog M +62 -2 src/contextbrowser.cpp --- trunk/extragear/multimedia/amarok/ChangeLog #620634:620635 @@ -45,6 +45,8 @@ you move and rename them. CHANGES: + * Support for cue files not matching audio files' name. Patch by Dawid + Wróbel <dawid@klej.net>. (BR 128046) * Script Manager now remembers if categories were open or closed. * Restart collection scanner as long as not more than 5 % of the files make it crash. (BR 106474) --- trunk/extragear/multimedia/amarok/src/contextbrowser.cpp #620634:620635 @@ -649,14 +649,74 @@ if (trackChanged && bundle.url().isLocalFile()) { - // look if there is a cue-file + + /** The cue file that is provided with the media might have different name than the + * media file itself, hence simply cutting the media extension and adding ".cue" + * is not always enough to find the matching cue file. In such cases we have + * to search for all the cue files in the directory and have a look inside them for + * the matching FILE="" stanza. However the FILE="" stanza does not always + * point at the coresponding media file (e.g. it is quite often set to the misleading + * FILE="audio.wav" WAV). Therfore we also have to check blindly if there is a cue + * file having the same name as the media file played, as described above. + */ + + // look for the cue file that matches the media file played first QString path = bundle.url().path(); QString cueFile = path.left( path.findRev('.') ) + ".cue"; m_cuefile->setCueFileName( cueFile ); if( m_cuefile->load() ) - debug() << "[CUEFILE]: " << cueFile << " found and loaded." << endl; + debug() << "[CUEFILE]: " << cueFile << " - Shoot blindly, found and loaded. " << endl; + + // if unlucky, let's have a look inside cue files, if any + else + { + debug() << "[CUEFILE]: " << cueFile << " - Shoot blindly and missed, searching for other cue files." << endl; + + bool foundCueFile = false; + QDir dir ( bundle.directory() ); + dir.setFilter( QDir::Files ) ; + dir.setNameFilter( "*.cue *.CUE" ) ; + + QStringList cueFilesList = dir.entryList(); + + if ( !cueFilesList.empty() ) + for ( QStringList::Iterator it = cueFilesList.begin(); it != cueFilesList.end() && !foundCueFile; ++it ) + { + QFile file ( dir.filePath(*it) ); + if( file.open( IO_ReadOnly ) ) + { + debug() << "[CUEFILE]: " << *it << " - Opened, looking for the matching FILE stanza." << endl; + QTextStream stream( &file ); + QString line; + + while ( !stream.atEnd() && !foundCueFile) + { + line = stream.readLine().simplifyWhiteSpace(); + + if( line.startsWith( "file", false ) ) + { + line = line.mid( 5 ).remove( '"' ); + + if ( line.contains( bundle.filename(), false ) ) + { + cueFile = dir.filePath(*it); + foundCueFile = true; + m_cuefile->setCueFileName( cueFile ); + if( m_cuefile->load() ) + debug() << "[CUEFILE]: " << cueFile << " - Looked inside cue files, found and loaded proper one" << endl; + } + } + } + + file.close(); + } + } + + if ( !foundCueFile ) + debug() << "[CUEFILE]: - Didn't find any matching cue file." << endl; + } } }
Thanks for fixing your bug and your first OS contribution! I could not test it, but as you are the original reporter, I assume that the problem is really resolved. Next time, please don't include files unrelated to the bug resolution (in this case amarok.kdevelop) in the patch.
I knew about that amarok.kdevelop but eventually forgot to delete it from svn diff output. Thanks for your quick response.