Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC decoder testbench (Read 3014 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC decoder testbench

Reply #26
I just sent in a patch to fix both problems in flac: https://github.com/xiph/flac/pull/257 If anyone wants a binary let me know.
Music: sounds arranged such that they construct feelings.

Re: FLAC decoder testbench

Reply #27
I've just uploaded a new testbench, revision 5. Link can be found on the wikipage.

This revision has all testfiles replaced, the testbench is now licensed CC0 1.0. This revision should also fix the following two issues:

By the way, evaluation of correct/incorrect playback speed for non-44.1 files (19-21) on unfamiliar material, especially on chiptune-like music, is not very straightforward.
Just a comment on the foobar2000 entry in the table: for me it doesn't actually play file 55 properly
The first because all files now include a spoken description and there is no chiptune used, the second because current stable Foobar2000 always crashes on file 55 on my end. It doesn't even import properly now.

I'll redo the hardware player checks I've done previously. If you have any hardware capable of playing FLAC, testing it with this testbench and sharing the results would be most welcome.
Music: sounds arranged such that they construct feelings.

Re: FLAC decoder testbench

Reply #28
Opened it and saw something I didn't even think of: there is no mono file. Maybe an insult to the decoders ... but then I also thought of: left/side, right/side, mid/side channel assigments 1000/1001/1010?

As for foobar2000, 1.6.8 beta 5 handles it; foo_verifier gives a warning over file 45 (no total number of samples set), but I just let it ReplayGain scan and tag the files, and rewrite tags; then started afresh and rewrote tags and then ReplayGain scanned and tagged. Works fine, but once it gets to writing 48 to, it spends time. It doesn't support AVIF, but says it is present.
Pretty much the same with Mp3tag (3.08) too.

Oh, and at least when the test bench goes final, it might be an idea to have the readme available separately, so one doesn't have to download everything to get it. I took the liberty to attach it here in case it is useful to anyone.
High Voltage socket-nose-avatar

Re: FLAC decoder testbench

Reply #29
Opened it and saw something I didn't even think of: there is no mono file. Maybe an insult to the decoders ... but then I also thought of: left/side, right/side, mid/side channel assigments 1000/1001/1010?
Yes, I was thinking of adding a mono file. The stereo decorrelation things are simply 'in the mix': they are so common I don't expect any developer needing a specific test file for it. This is also the case with things like LPC orders: there is no file that specifically test all orders, but they're all in there, somewhere.

I was just thinking of something else: the FLAC specification isn't quite clear on whether or not certain parameters are allowed to change mid-file, like bitdepth, number of channels and samplerate. There are certain codecs that do things like that, for example AC3 in TV streams does it all the time, switching from stereo to multichannel.

Perhaps not something to add to this testbench, but to a different one more focused on potential security issues with crafted files.
Music: sounds arranged such that they construct feelings.

Re: FLAC decoder testbench

Reply #30
The following tests done on a Dell laptop (running Windows 10) through its stereo speakers, no fancier audio devices. I cannot tell what is supposed to be "expected downmixing to stereo", and I cannot know for sure whether Spotify generally refuses to play multichannel, or because it can figure out it is talking to a stereo device.

Spotify for Windows version 1.1.72.439.gc253025e: Here I had to let the library point at the folder for local files.
Tracks 48 through 52 are rejected and so is 55; they are not even indexed by the player. 
Tracks 22 and 36 through 44 skip.  44 after seemingly playing silence for four or five seconds before skipping the last ten-ish - but I cannot rule out that the progress bar just runs while it in reality Spotify spends this time to figure out that it is something it wants to skip.

fb2k 1.6.8: like the beta but unlike previous versions, it now handles everything.

Can also confirm the wiki entries for: VLC and SMPlayer 21.8.0 using mpv 0.32.0.

High Voltage socket-nose-avatar

Re: FLAC decoder testbench

Reply #31
Oh, wait. While VLC for all "end-user-practical" purposes hangs at the infamous 55, it is actually "just" spending minutes processing the file before playing it.

Reason I found out: I tried ffplay, which does the same thing but starts playback much faster.  Went back to VLC then. Also tried MPlayer.exe (in the SMPlayer bundle). And mpv.exe, which was so stuck forever that I'm killing it rather than waiting overnight.

I'd say nobody wants to wait neither one nor four minutes though.


VLC on files 27 and 55, opening the messages and media information windows:
27 - old format variable blocksize file created with Flake 0.11.flac Gnaws at the file but one can skip back and forth in the playlist. After some three minutes it makes a short noise, and then apparently it consider itself done with the file.
55 - file 48-53 combined.flac : Starts playing after three to four minutes. If I have another window on top, a popup with metadata infomation shows up in around 100 seconds, that is way earlier than metadata shows up in the Ctrl-i information window.
51 - Extremely large VORBISCOMMENT.flac : Traces of "as 55" - but hangs only for three to four seconds, that is tolerable. (Also 54 hangs for a second.)


ffplay version 4.4.1-essentials_build-www.gyan.dev . Invoked through a FOR loop with -autoexit
03 - blocksize 16.flac plays at like 1/6th of intended speed. Totally unlistenable, of course.
55: Because I see metadata output to terminal window, I can tell it is technically not hanging. Without it, I wouldn't have had the patience. But after 70 seconds, it plays.


MPlayer.exe reported to be the following:
MPlayer Redxii-SVN-r37955-6.2.0 (x86_64) (C) 2000-2017 MPlayer Team
Using FFmpeg N-87137-g6ccd32c367 (2017-08-30 20:24:28 +0200)
Compiled on 2017-09-09 13:22:37 EDT (rev. 1)

36: Stuck at outpt like A:  -1.0 (unknown) of 8.0 (08.0) ??,?%, but I can use right arrow (which is supposed to seek 10 seconds!) to get to 6 seconds-ish. It then plays the last couple of seconds.
I think that is a "Fails" when user can skip and get to next without program restart?
55: Plays - but spends around 80 seconds before playing audio.

(MPlayer makes some other quirks that do not affect playback, like showing the GIF as a green rectangle. And I've seen strange times on the 27 on other players too.)

High Voltage socket-nose-avatar