Support for Opus codec about slimserver HOT 59 CLOSED

Hi guys, I changed my mind about Opus and merged Jeff's great patch into Audio-Scan 1.01. Hope this helps!

https://github.com/andygrundman/Audio-Scan
https://metacpan.org/release/Audio-Scan

from slimserver.

BTW: this was one of the nicest LMS collaborations I've seen in a while, from contributors old and new ;-)

from slimserver.

Reposting from the Audio-Scan issue, for the benefit of those watching this one:

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;

from slimserver.

I'm reopening this, now that Andy has been kind enough to take the initial, important step.

from slimserver.

The problem is the Audio/Scan.pm included with LMS is expecting 0.93. But the binary LMS finds is 1.02. You'd have to include the Perl part with your bundle and put it in the arch specific folder. This way it takes precedence over the one included with LMS.

from slimserver.

Hi folks, sorry to post this to the developer forum, but I'm not getting any resonance on the user forum: https://forums.slimdevices.com/showthread.php?107011-Howto-play-Ogg-Opus-files/page4

My main questions / challenges:
1.) The majority of my opus files don't get picked up by the scanner. They appear to be simply ignored. (see thread and log extract on slimdevices)
2.) On files that do scan, Replay Gain tags are ignored. (I can potentially work around this. 1.) is more urgent)

I tend to agree with ghost tbh, opus is one of the best (ie quality for bandwidth) and most future proof lossless audio codecs around and it is the new internet standard. I'd love to see LMS include fully functional support for it.
(transcoding from opus to FLAC seems to work great on my setup, btw)

pls lmk how I can support troubleshooting. Glad to help.

from slimserver.

I'm sorry, no plans. Maybe you could ask Andy, author of the Audio::Scan module we're using:

https://github.com/andygrundman/Audio-Scan

from slimserver.

I'll comment here to keep the discussion in one place. So, the good news is that adding Opus support to Audio::Scan would not be much work, probably about on the level of the work that was done for DSD support recently. There would be 4 bits of work needed in Audio::Scan:

1. Parse the info header. https://wiki.xiph.org/OggOpus#Packet_Organization
2. Parse the comments (tags). No extra work as the comments are Vorbis comments.
3. Seek offset calculation, which may or may not work just like in Ogg files.
4. Comprehensive test suite. Probably start with https://people.xiph.org/~greg/opus_testvectors/

After all this stuff, it's relatively easy to add to LMS as a new transcoded file format.

All that being said, can you explain your use case a bit? Are these your own encoded Opus files or are they from somewhere else? If they are your own, why do you prefer Opus over FLAC? I think Opus is great for things like low-latency voice chat, but I don't see a reason to use it for music. I'm not trying to discourage you, just pointing out that the chances of this getting worked on are pretty slim (no pun intended).

from slimserver.

Thanks Andy, my case is pretty simple:
I encoded the files myself (on Windows) using the downloads from xiph.org.
I'm simply trying to get the best possible sound quality for a given bitrate (=Opus codec?), because I have a couple of (Rockbox-based) players with limits on the SDHC-card size - and they play Opus just fine.
I just bought a couple of cheap Raspberry Pi's where I use PiCorePlayer - I really like the combination, so
why not use the Opus files on the pi's, instead of having all my music duplicated using another codec?
And last, but not least: I'm 65, so lossless encoding is only used for archiving purposes :-)

from slimserver.

FWIW: somebody seems to have patched Audio::Scan to support Opus: https://github.com/jrmuizel/AudioScan-opus/.

Somebody else further developed LMS support: http://forums.slimdevices.com/showthread.php?t=107011

from slimserver.

Thanks a lot, I'll follow the discussion(s)

from slimserver.

Hi, just for the question "Why to support Opus?" Because it is the standard of the future. Opus will also be the standard of the broadcasting industry as all new hardware in this business will support Opus.

See this posting on the mozilla blog: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/

from slimserver.

Any change of plans to support opus in LMS?

from slimserver.

You should be able to build this for your own use pretty easily. Did you try to do so? Head over to Andy‘s repository to get the latest and greatest.

from slimserver.

Thanks Michael, but I'm not into development - I'm a github user because I want to be able to report issues and make feature requests, I only use Linux on my tiny PCPs (normal desktop is Windows).

I realize that you do this in your spare time, that there are tons of real problems for you to deal with, and that implementing just another lossy codec doesn't exactly get top priority, so please close the issue with whatever code you find suitable.

from slimserver.

Assuming PCP refers to piCorePlayer, you might want want to get in touch with @paul-1 and ask him whether an update would be possible. He's the guy behind LMS on pCP (and many more aspects of pCP).

from slimserver.

Audio Scan is a pretty easy update. If we do update it, will LMS/Squeezelite handle playing OPUS files?

from slimserver.

Good point!... There's a "patch" for LMS available in https://forums.slimdevices.com/showthread.php?107011.

from slimserver.

The patch is going to be harder to deal with unless that's something you can merge into 7.9.2

Can you do module checks to enable the opus file type?

if Audio::Scan >= 1.01 then 'ops' => 'Slim::Formats::OggOpus',

from slimserver.

I consider adding this to 7.9.2, as it's rather lightweight anyway. Would our recent sox builds support decoding Opus?

from slimserver.

@grummisch - could you please provide a sample file?

from slimserver.

libopus is available to be easily added, but I'm not sure the version of sox in LMS allows for extra codecs dynamically loaded. @ralph-irving?

from slimserver.

Sample file:
take_your_finger_from_my_hair.zip
There you are - just a quick one, can easily supply more

from slimserver.

Yes, we would need to rebuild the sox binaries with opus support. I already have a modified buildme.sh to include opus support in sox, been using it since Roland0 posted the howto on the forum. Traveling ATM so can't attach it.

from slimserver.

I've created the branch https://github.com/piCorePlayer/slimserver-vendor/tree/soxopus containing the sox build script changes to include opus. @paul-1 would you test the buildme-pcp.sh script? I can rebuild the sox binaries for LMS over the next few days if the plan is to move forward with opus support.

from slimserver.

Thanks Ralphy, now I’m traveling. I’ll be able to do it later in the week. @mherger. Any chance you can make the LMS mods for this? A separate test branch would make it easier for me to build a full test package.

from slimserver.

@paul-1 I might be a bit busy this week, too. But I'd let you know. Thanks!

from slimserver.

As I build the sox-dsd-opus binaries I'm uploading them to https://sourceforge.net/projects/lmsclients/files/utility/sox-opus/20181010-9da8441/ I will post another update once complete.

from slimserver.

I built the new sox, seemed to check out fine, it was able to read the opus sample file. As soon as LMS updates are made, will do a full test.

from slimserver.

@paul-1 I've created a brunch public/feature/opus which should have the necessary changes. I haven't tested this, as I haven't found the time to build Audio::Scan yet. And it's only loading the OggOpus module if Audio::Scan >= 1.01 is installed (you know where in Slim::Formats). Good luck - and thanks for the testing!

from slimserver.

I've completed building sox with opus support. They are available in the URL above and I uploaded a sox-opus-all zip to the usual pcp team file share. Zip includes an armhf binary which should work on older raspbian system too and is not the same as the pcp build from Paul.

from slimserver.

Packages built for piCorePlayer, the test file is scanned and plays okay.

from slimserver.

Thanks both of you!
@paul-1 using my opus branch? I'll merge it then.
@ralph-irving could you please send me a pull request for the changes to the build scripts?

from slimserver.

I'm having an issue where Audio:Scan is ignore some local opus files I created using the latest opusenc tool. Still researching it. I've put the opus tools build script and sources on github https://github.com/ralph-irving/opustools You'll find the binaries are in the opus-tools-0.2 folder after building.

from slimserver.

There are 2 opustestfile zip files on the pcp db share. I converted from flac to opus, one source was 44.1KHz and the other 48KHz. @paul-1 would you try scanning them?

from slimserver.

Works fine here.

from slimserver.

I wasn't looking closely enough, infact tracks are missed. All tracks are found by the scanner, identified as Audio, but some of the tracks don't end up in the database. No errors are in the log.

from slimserver.

@ralph-irving There is some info missing in the Metadata,

This is basically the first thing done after getting the tags from the file (Slim::Formats::Ogg)
return unless $info->{song_length_ms};

I wrote a quick program to pull the tags out (Using Audio::Scan), you can see that tag missing from the track that wasn't added. Not sure yet if it is the encoder, or Audio::Scan. Do you have a different MetaData reader?

Track: /mnt/data/Music/Carol King/Tapestry/009-WillYouLoveMeTomorrow.opus
ALLPICTURES => ARRAY(0xac7e70)
TITLE => Will You Love Me Tomorrow?
ENCODER => opusenc from opus-tools 0.2
VENDOR => libopus 1.2.1, libopusenc 0.2.1
DATE => 1971
TRACKNUMBER => 09
ENCODER_OPTIONS => --bitrate 192 --vbr --music
GENRE => Pop
ARTIST => Carole King
ALBUM => Tapestry (opus)
samplerate => 48000
version => 1
channels => 2
file_size => 6503669
audio_size => 6452652
bitrate_average => 204816
stereo => 1
audio_offset => 51017
jenkins_hash => 608158155
song_length_ms => 252036
serial_number => 1418794509
input_samplerate => 48000
preskip => 312

Track: /mnt/data/Music/Carol King/Tapestry/010-SmackwaterJack.opus
ALLPICTURES => ARRAY(0xac8248)
TITLE => Smackwater Jack
VENDOR => libopus 1.2.1, libopusenc 0.2.1
ENCODER => opusenc from opus-tools 0.2
TRACKNUMBER => 10
DATE => 1971
GENRE => Pop
ENCODER_OPTIONS => --bitrate 192 --vbr --music
ALBUM => Tapestry (opus)
ARTIST => Carole King
preskip => 312
serial_number => 1833061797
input_samplerate => 48000
jenkins_hash => 2860671313
audio_offset => 51017
stereo => 1
audio_size => 5549081
version => 1
channels => 2
file_size => 5600098
samplerate => 48000

from slimserver.

It’s probably an Audio::Scan issue if that field is missing. I’ll take a look if you can send me those files.

from slimserver.

The opus encoder transfers the flac tags to the opus file automatically, but the length is not a flac tag.

@paul-1 I just have the opusinfo tool.
$ opusinfo 009-WillYouLoveMeTomorrow.opus
Processing file "009-WillYouLoveMeTomorrow.opus"...

New logical stream (#1, serial: 5491160d): type opus
Encoded with libopus 1.2.1, libopusenc 0.2.1
User comments section follows...
ENCODER=opusenc from opus-tools 0.2
METADATA_BLOCK_PICTURE=3|image/jpeg||500x500x24|<37268 bytes of image data>
ENCODER_OPTIONS=--bitrate 192 --vbr --music
ARTIST=Carole King
DATE=1971
GENRE=Pop
TITLE=Will You Love Me Tomorrow?
TRACKNUMBER=09
ALBUM=Tapestry (opus)
Opus stream 1:
Pre-skip: 312
Playback gain: 0 dB
Channels: 2
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 996.3ms (avg), 60.0ms (min)
Total data length: 6503669 bytes (overhead: 1.34%)
Playback length: 4m:12.036s
Average bitrate: 206.4 kbit/s, w/o overhead: 203.7 kbit/s
Logical stream 1 ended

$ opusinfo 010-SmackwaterJack.opus
Processing file "010-SmackwaterJack.opus"...

New logical stream (#1, serial: 6d424da5): type opus
Encoded with libopus 1.2.1, libopusenc 0.2.1
User comments section follows...
ENCODER=opusenc from opus-tools 0.2
METADATA_BLOCK_PICTURE=3|image/jpeg||500x500x24|<37268 bytes of image data>
ENCODER_OPTIONS=--bitrate 192 --vbr --music
ARTIST=Carole King
DATE=1971
GENRE=Pop
TITLE=Smackwater Jack
TRACKNUMBER=10
ALBUM=Tapestry (opus)
Opus stream 1:
Pre-skip: 312
Playback gain: 0 dB
Channels: 2
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.7ms (avg), 940.0ms (min)
Total data length: 5600098 bytes (overhead: 1.46%)
Playback length: 3m:41.916s
Average bitrate: 201.9 kbit/s, w/o overhead: 198.9 kbit/s
Logical stream 1 ended

from slimserver.

Thanks, this is definitely an issue with Audio::Scan, it doesn't always parse the Ogg packets properly. Specifically, final_serialno is sometimes read from the wrong point in a packet which causes the duration to not be set. I'll see if I can figure it out.

from slimserver.

A rainy day here, so I played with the code..... There is a problem with the buffer logic, where the opus.c seeks to the end of the file, and then steps backwards through the file to find the last packet header. I started to go cross-eyed looking at the code, so I just increased the buffer so that it "should" be large enough to find the last header.

This takes care of the test files not reading.......but obviously is just a band-aid.

 diff Audio-Scan-1.01/src/opus.c opus.c
254c254
<   DEBUG_TRACE("Buffer clear");
---
>   DEBUG_TRACE("Buffer clear\n");
267c267
< #define BUF_SIZE 8500 // from vlc
---
> #define BUF_SIZE 17000 // from vlc

from slimserver.

I checked in a minimalist fix, the root cause was simply that the buffer was not being cleared when seeking further back into the file. I left the buffer size at 8500 because it helps test the seek code, but I don't know where this number came from. Looking at the opusfile library, 64K seems to be the right value to use, because there is no blocksize hint as there is in Vorbis.

I still want to do some more cleanup work on this, but hopefully it will be able to scan all your files now.

from slimserver.

1.02 Looks good on my end.

from slimserver.

Thanks a lot all of you guys! I merged the necessary changes to public/7.9.

Binaries remain to be added/updated. I only added macOS binaries so far. Will add more when needed and available :-).

from slimserver.

@michaelherger I uploaded a zip with all the sox-opus-binaries to the picoreplayer dropbox share a few days ago and submitted the PR for the sox opus source changes.

from slimserver.

@grummisch The pCP binary package has been updated.

Assuming your running pCP 4.0.0......first thing, do a nightly update on LMS. Then on the pCP web page, on the LMS tab, there is a button to "Update Libs"

After all the updates are done, you should be good with your opus files. If you have problems, please respond in the pCP support thread. https://forums.slimdevices.com/showthread.php?109404-ANNOUNCE-piCorePlayer-4-0-0

from slimserver.

I'm on pCP 4.0.0 - unfortunately I'm stuck already on the nightly update:

Only place I could find the words nightly update was on the pCP web page, on the LMS tab;
I press the Nightly Update button - result:

No Update file was found, Please check LMS Server configuration.
Click Configure Below.
Then go to Advanced Tab, Software Updates Dropdown Box.
Make sure Automatic Updates and Frequency are set to your needs, or Check for Updates Manually.

My Software Updates settings:
Don't check for software updates, Do not automatically download updates

Clicking the Check for updates now button:

A new version of Logitech Media Server is available (7.9.0). Click here to download.

When the link is clicked:

New tab named Index of /LogitechMediaServer_v7.9.1 opens
Some LogitechMediaServer-7.9.1* files are shown, all dated 17-Apr-2018

I assume I'm in the wrong place, and go no further...

Sorry about the fuss, normally I only do pCP release updates...

from slimserver.

Did you try this procedure? https://www.picoreplayer.org/how_to_upgrade_lms.shtml

from slimserver.

NO!
After that hint everything progressed fine.
I can only second your remark about collaboration, it has been amazing to be at sideline and watch all you good folks work together on this - thank you all!

from slimserver.

@grummisch good to hear you're all set!

@paul-1 I think there's a problem right now for people who want to install LMS on pCP without the manual procedure. There's been a report in the forum, too (http://forums.slimdevices.com/showthread.php?t=109613)

from slimserver.

from slimserver.

from slimserver.

Would it be possible to also provide an opusdec binary until squeezelite gets Opus support?
(See https://code.google.com/archive/p/squeezelite/issues/74 - waiting for Opus support in LMS)
Reason: limit network traffic on my minimalist setup of pi-zero Ws connected by WLAN

from slimserver.

The sox binaries included with the latest LMS 7.9.2 already have support for decoding opus streams. There are no plans to add opus support to squeezelite. Not sure why you're referencing squeezelite on googlecode. Current development for squeezelite is on github https://github.com/ralph-irving/squeezelite

from slimserver.

1. I know decoding is supported, but FLAC uses more network bandwith than Opus, and I suppose the LMS server itself is loaded more because of the Opus->FLAC conversion(s). I'm aware that the players then probably have a much easier task decoding FLAC instead of Opus.
2. No Opus support plans for Squeezelite: then I'd really like an opusdec binary to be provided - it surely must have been built during the testing.
3. Sorry about the Squeezelite homepage fuzz, should have spent more time searching.

from slimserver.

With all due respect: get a Pi3b and you're all set. We've gone a long way already to implement this rather exotic request. Let's not over-optimize either.

from slimserver.

From the Audio::Scan perl module version 1.08 or newer has improved ogg/opus scanning support, but not all platforms include the latest release, which is actually 1.10. See https://github.com/LMS-Community/Audio-Scan

from slimserver.

From the Audio::Scan perl module version 1.08 or newer has improved ogg/opus scanning support, but not all platforms include the latest release, which is actually 1.10. See https://github.com/LMS-Community/Audio-Scan

Yeah, I've deleted my comment shortly after posting it. The issue was with sox not being installed.

from slimserver.