SUMMARY Opus is the successor to the Vorbis audio codec. Both are usually stored in a OGG container, however for Opus the extension is typically .opus and not .ogg, but I have run into several cases where a .ogg file contained an Opus stream. However, unlike any other media player I tried, Elisa will only play Opus if the extension is .opus, and it will only play .ogg if the codec is vorbis. STEPS TO REPRODUCE 1. Encode some audio with libopus with ffmpeg, give it the file extension .ogg 2. Open it in Elisa 3. Rename it to .opus 4. Try again OBSERVED RESULT Elisa will only play the file once it has been renamed to .opus, not .ogg, and seemingly assumes that .ogg files always contain a Vorbis stream. EXPECTED RESULT Elisa should detect that the OGG container contains an Opus stream and play it, regardless of the file extension SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2
Just realized I'm also running into this. I intentionally named all my Opus-encoded music with the ".ogg" extension so that it could easily sync with my Android phone, because Android does not support the ".opus" extension before version 10. Seeing Elisa have essentially the same bug but in the opposite direction is funny, in a depressing kinda way...
That's weird, Elisa does advertise support for ogg files: application/x-ogm-audio;audio/x-vorbis+ogg;audio/ogg Can you run `file --mime-type [path to file]` on one of those files and paste the output here?
file --mime-type gives me audio/ogg, regardless of extension: brendon@theta:~/media/music/cds/Audioslave/Audioslave$ mv 01.\ Cochise.ogg 01.\ Cochise.opus brendon@theta:~/media/music/cds/Audioslave/Audioslave$ file --mime-type 01.\ Cochise.opus 01. Cochise.opus: audio/ogg brendon@theta:~/media/music/cds/Audioslave/Audioslave$ mv 01.\ Cochise.opus 01.\ Cochise.ogg brendon@theta:~/media/music/cds/Audioslave/Audioslave$ file --mime-type 01.\ Cochise.ogg 01. Cochise.ogg: audio/ogg Now if I run QT_LOGGING_RULES="*.elisa.*=true" elisa and then try to open the ".ogg" file in Elisa (from Dolphin), I get this output: org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries 1 org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries QMap((DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg")))(DataTypes::ElementTypeRole, QVariant(int, 5))) org.kde.elisa.playlist: MediaPlayList::enqueueMultipleEntries new url QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg") ElisaUtils::Track org.kde.elisa.indexer: scanOneFile QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg") using KFileMetaData QMap((DataTypes::RatingRole, QVariant(int, 0))(DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg")))(DataTypes::FileModificationTime, QVariant(QDateTime, QDateTime(2022-08-23 11:07:54.972 EDT Qt::LocalTime)))(DataTypes::ElementTypeRole, QVariant(int, 5))) qrc:/qml/MediaPlayListView.qml:296:33: Unable to assign [undefined] to bool However, when I rename the file to ".opus", the interesting difference starts here: org.kde.elisa.indexer: scanOneFile QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus") using KFileMetaData QMap((DataTypes::TitleRole, QVariant(QString, "Cochise"))(DataTypes::DurationRole, QVariant(QTime, QTime("00:03:42.000")))(DataTypes::ArtistRole, QVariant(QString, "Audioslave"))(DataTypes::AlbumRole, QVariant(QString, "Audioslave"))(DataTypes::TrackNumberRole, QVariant(int, 1))(DataTypes::RatingRole, QVariant(int, 0))(DataTypes::YearRole, QVariant(int, 2002))(DataTypes::ChannelsRole, QVariant(int, 2))(DataTypes::BitRateRole, QVariant(int, 120000))(DataTypes::SampleRateRole, QVariant(int, 48000))(DataTypes::ResourceRole, QVariant(QUrl, QUrl("file:///home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus")))(DataTypes::HasEmbeddedCover, QVariant(bool, false))(DataTypes::FileModificationTime, QVariant(QDateTime, QDateTime(2022-08-23 20:26:17.835 EDT Qt::LocalTime)))(DataTypes::ElementTypeRole, QVariant(int, 5))) org.kde.elisa.playlist: MediaPlayList::trackChanged QVariant(QString, "Cochise") I'm guessing the relevant implementation of scanOneFile() is the one in filescanner.cpp, which initially creates a list of candidate extractors. Evidently a candidate is chosen (else it would say "no extractors"), but it seems that extractor ultimately fails to actually extract any metadata. This may (or may) not be the cause of Elisa not reading the ".ogg" file - I notice it does add a "no entry" icon to the playlist, but plays nothing. (FWIW, my Elisa is at 21.08.3, but my Frameworks which has KFileMetaData is at 5.97.0.)
Good sleuthing! Would you be interested in continuing to investigate and submitting a merge request to https://invent.kde.org/multimedia/elisa/-/merge_requests?
I wouldn't expect to have time to get as far as a merge request, but I can probably do more sleuthing. I just took another dive into the code and found that the likely extractor is the one based on Taglib. So I installed pytaglib and tried to open the file. In python3: >>> import taglib >>> song = taglib.File("/home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "src/taglib.pyx", line 87, in taglib.File.__cinit__ OSError: Could not read file /home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.ogg Well, I'm pretty sure I didn't get the path wrong. I tried renaming the same file to ".opus", and then: >>> song = taglib.File("/home/brendon/media/music/cds/Audioslave/Audioslave/01. Cochise.opus") >>> song.tags {'ALBUM': ['Audioslave'], 'ARTIST': ['Audioslave'], 'COMPILATION': ['false'], 'DATE': ['2002'], 'ENCODER': ['opusenc from opus-tools 0.1.10'], 'ENCODER_OPTIONS': ['--bitrate 128'], 'TITLE': ['Cochise'], 'TRACKNUMBER': ['01']} So, if I'm not mistaken, conclusion is this is a bug in Taglib. Looking through the Taglib Github issues page, I found this: https://github.com/taglib/taglib/pull/1013 Judging by the dates, the fix has been in master for over a year, but no stable release in that time...
Aha that makes perfect sense. Yeah, TagLib needs to make a release.