Symfonium doesn't play ogg?

Support
1

Issue description:

I seem to have some tracks in ogg format that Symfonium refuses to play. They work in every other software I have, and Symfonium can even download them, after which I can play them locally using some other music app.

I do have “Prefer internal decoder” checked, but also “Transcoding engine”, which should make sure that even unsupported formats can be played? I’m surprised though that this one fails, as I see Vorbis in the list of formats. I guess it’s possible that my file is damaged somehow in a way that only Symfonium reacts to?

I’m actually a bit confused about these settings overall. If Symfonium can transcode a format, surely it can also decode it, as transcoding already includes decoding?

Logs:

Upload description: It asked for my nickname or identifier, so that’s what I entered (“ajp_anton”). Is that what this is? This field seems to ask for something different though…

Additional information:

 
In the log, I immediately went back to my track search, tried to play the track, waited a bit while it tried to start it, and then I stopped it.

I was expecting to be able to upload a sample track here somewhere.
 

Reproduction steps:

 
Try to play an .ogg file that works in other software. Have “Prefer internal decoder” and “Transcoding engine” checked.
 

Media provider:

Subsonic

Screenshots:

     

2

Here’s a sample track that Symfonium fails to play.

3

Where do you get those files.

Ffmpeg sees errors in it, audacity sees 3 different samples running at the same time, and the Google parser fails too since they are not really valid.

ffmpeg -i sample.ogg -f null -err_detect +crccheck+bitstream+buffer+explode+careful+compliant+aggressive -v error -xerror -
[ogg @ 0x5f5b05a640c0] failed to create or replace stream
[null @ 0x5f5b05a8f040] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1190144 >= 1190144
[null @ 0x5f5b05a8f040] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5048832 >= 5048832

image
image2048×1000 133 KB

4

The errors I could kind of understand - these have lived on my various hard drives for at least 15 years, maybe even 20. I’ve had many photos and videos go bitrot on me from those times. I downloaded ffmpeg and checked with that same command, and all 13 albums with 243 tracks (except one track!) have the exact same pattern of errors, so it has to be part of how they were constructed.

I have no recollection of where I got these after all this time. Just kind of found them in some long forgotten folder of old stuff on my HDD.

I had a closer look, and not all media software behaves the same. They all (except Symfonium) do play them, but

Windows:

  • MPC-HC: full 2:04 progress bar, but can’t seek, only plays 26 seconds.
  • Jriver Media Center: full 2:04 progress bar, seeks perfectly, plays perfectly.
  • Mediamonkey: perfect, same as above.
  • MKV Merge: skips everything past 26 seconds, also reflected in the filesize.

Android:

  • Mediamonkey: only 26s progress bar, within which it can seek, plays the whole 2:04.
  • Spotify: same as above
  • Total Commander’s integrader player: same as above
  • Samsung Video Player: same as above
  • Samsung Sound Player: I’m starting to see a pattern here
  • Voice Recorder: same

LMS (Lightweight Music Server): everything is labeled as being 10 seconds.

  • Access through Firefox on Windows: progress bar is 10s, can’t seek, but does play the whole thing.
  • Access through Supersonic on Windows: can’t seek, but it does recognize it as 2:04 (wtf?) and does play it all. Maybe it downloads the whole track and ignores what the server says about it.

Is your conclusion that it’s not worth doing anything about these (understandable), or try to get around the problem? Some players seem to have figured it out somehow… Maybe it was a common error a long time ago and some software still carry the old workarounds with them.

5

I could try to report to Google, but all the last attempts on invalid media had the same answer, it’s invalid media we don’t had invasive workaround.
Seeing how most have issues it’s not worth the trouble I think.