andygrundman / Audio-Scan

Audio::Scan - Fast Perl XS metadata and tag reader for all common audio file formats
GNU General Public License v2.0
3 stars 13 forks source link

Opus codec support #1

Closed ghost closed 6 years ago

ghost commented 7 years ago

Any plans? My .opus files are not recognized when scanning. I asked the question in the github.com/Logitech/slimserver project, and mherger pointed me here.

andygrundman commented 7 years ago

See my comment on https://github.com/Logitech/slimserver/issues/133

ghost commented 6 years ago

The thread https://github.com/Logitech/slimserver/issues/133 describes a possible solution to adding support for opus - will you consider adding it?

andygrundman commented 6 years ago

Thanks for pinging me. I do plan on integrating the patch from https://github.com/jrmuizel/AudioScan-opus/

andygrundman commented 6 years ago

After reviewing the existing Opus patch, I can't accept it. The samplerate is hardcoded to 48000 when the format definitely supports more than one samplerate. If anyone would like to continue work on Opus support, please fork this repo and do so via a pull request. I also can't stress enough that a proper set of tests is essential, with test files that cover the range of possible Opus encoding options.

my_hv_store( info, "samplerate", newSViv(48000) );
samplerate = 48000;
ghost commented 6 years ago

I think maybe the sample rate is part of the specification? https://wiki.xiph.org/OpusFAQ#Does_Opus_support_higher_sampling_rates.2C_such_as_96_kHz_or_192_kHz.3F ...

andygrundman commented 6 years ago

Opus supports constant and variable bitrate encoding from 6 kbit/s to 510 kbit/s, frame sizes from 2.5 ms to 120 ms, and five sampling rates from 8 kHz (with 4 kHz bandwidth) to 48 kHz

https://en.wikipedia.org/wiki/Opus_(audio_format)#Bandwidth_and_sampling_rate

If hardcoding the samplerate was actually the right thing to do, this would be so crazy to AT LEAST deserve a comment or two.

andygrundman commented 6 years ago

If I'm missing something dumb here, forgive me, but any format that would limit you to a single samplerate or even max out at 48k is very shortsighted and obviously not something any of us in the audiophile or wannabe-audiophile crowd should be worried about supporting, right? I'm getting old and probably can't blind-test my 24/96 FLACs from the CDs on most days, but I like knowing the extra data is there anyway.

ghost commented 6 years ago

Obviously, I didn't do my homework - how about implementing just the 48k samplerate (which is what 99.999% will use), and leave the other (speak-) samplerates to be implemented in the future?

A digression: my interest in codecs is inspired by forums like hydrogenaud.io and it seems that Opus by no means is regarded as inferior (listening-wise) in lower bitrates - most people report having trouble ABXing Opus above 80kbit. When will a future lossy codec be considered good enough, audiophile-wise, to deserve implementation? Surely, most lossy codecs already implemented wouldn't qualify?

andygrundman commented 6 years ago

Sorry for the hasty reply last night, I think the disconnect here is just one of philosophy and maybe a little bit of me being an old man. From my point of view, Audio-Scan's main purpose is one of scanning large collections of music files. These will contain a lot of stuff collected over the years, varying from things like my early MP3 encodes, moving on to the time I was into Vorbis for a while, to modern high-res FLAC rips from Blu-rays, etc. For someone like me, the work on newer modern lossy codecs like Opus is pretty uninteresting, because the problem of lossless sound archiving has basically been solved. It doesn't seem likely anytime soon that we will need much better than FLAC for all audio needs. Storage space for audio is a non-issue these days, even on portable devices, when you can buy a 128GB microSD card for $25, and it is trivial to convert from anything into FLAC using ffmpeg and similar tools.

So to me, I have a hard time understanding why anyone is creating new lossy encodes in Opus format, as awesome as it is, when you could just use a lossless encode. And trust me, I feel like such an old geezer writing a sentence like that.

Now, as for the technical aspect, I am 100% with you that it's fun and interesting to implement new codecs, carefully read the specs, make test files, etc, etc, this is stuff I love to do and hopefully you can see this in the rest of Audio-Scan. I would absolutely accept Opus if it had this level of love and care brought to it as the other formats. Mostly I'm talking about test files here. The current patch has just 2 tiny test files and a really bare bones set of tests. I just don't have the tuits to flesh that out right now to a level of quality that I feel good about. So if someone has this passion for Opus hacking please dive in, and I'll stop being a grumpy old man about it. :)

ghost commented 6 years ago

If you're interested, please write me a PM with the (minimum) requirements of the test files, I'll have a look and see if it's within my capabilities to help? BTW, I totally agree that storage price is NOT an excuse for using lossy codecs - but I like my two media (audio) players, they both have a 32GB SDHC limit, the same goes for my PiCorePlayers running 24/7 from SDHC (no HD attached) at very low power consumption. So FLAC is out of the question in the current configuration...