Opus support? {Implemented with a 3rd party plug-in by thinktink)

[thinktink]

Version 2.0.13.28 now available through here.

Changes:

• Fixed third-party application issue dealing with old version of Winamp metadata API.
• Accidentally found and fixed a memory leak.

[EDIT/]
Whoops, that's what I get for mindlessly copying and pasting the previous posts version update information, updated to reflect the actual new version.

[thinktink]

Version 2.0.12.27 now available through here.

Changes:

• Changed load order of libopus dependencies to make more compatible with non Winamp hosts.
• Found and fixed a potential memory mismanagement error during plugin exit/unload.
• [REDACTED] changes for [REDACTED] [DATA EXPUNGED] involving [REDACTED] experiment.

[thinktink]

I'm pleased to announce the release of opusfile 0.12

The opusfile library provides seeking, decode, and playback of Opus
streams in the Ogg container (.opus files) including over http(s) on
posix and windows systems.

opusfile depends on libopus and libogg. The included opusurl library
for http(s) access depends on opusfile and openssl.

Changes since the v0.11 release:

- Fix stack overflow buffering out-of-sequence streams.
- Fix possible divide-by-zero.
- Fix issues with seeking in the win32 backend.
- Fix an issue where the seek algorithm could be confused
by stream data changing between reads.
- Clean up compiler and scan-build warnings.
- Avoid use of the deprecated ftime() function
which has Y2038 problems.
- Remove undefined behaviour memcpy(NULL) in op_read_native().
- Visual Studio project files updated for libogg 1.3.4 library name
change.
- Various build systems updates.
- Various integration and testing environment improvements.

This release is backward-compatible with the previous release. We
recommend all users upgrade.

Note that because of the removal of certificate store hooks in openssl
1.1.1 and later, there are unfortunately no supported versions of that
library which can be used with the code in opusurl to validate https
responses against the system certificate store on Windows. Using the
system default access to the certificate store on other platforms works
fine.

Source code:

https://downloads.xiph.org/releases/opus/opusfile-0.12.tar.gz

https://downloads.xiph.org/releases/opus/opusfile-0.12.zip

SHA-256 checksums:


118d8601c12dd6a44f52423e68ca9083cc9f2bfe72da7a8c1acb22a80ae3550b opusf
ile-0.12.tar.gz

7f44575596b78d7787c1865b9653e2a71546ff1ae77d87c53ab16dcc7af295ba opusf
ile-0.12.zip

No Windows build is available for this release. Developers should
integrate the source code directly into their applications.

Programming documentation is available in tree and online at
https://opus-codec.org/docs/.

The library is functional, but there are likely issues we didn't find
in our own testing. Please give feedback on this mailing list, in #opus
on irc.freenode.net, or at https://gitlab.xiph.org/xiph/opusfile.

Thanks to everyone who contributed!


Ralph Giles
Xiph.Org Foundation for Open Multimedia
_______________________________________________
opus mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/opus

Because of the requirements for Windows on this release it looks like I'll have to do a major rewrite of the opus handling functions to integrate these changes. It might take a while since my job usually leaves me exhausted by the end of the day.

[thinktink]

Hi thinktink,

I've been loading some opus files into Winamp today using your latest plugin version 2.0.10.22.

Most of them work great thanks. Though I've hit a couple where I can't get the tags to load into Winamp. They've been tagged in the same way as the other files which work (using AudioShell), and I can see the tags are present in the same way as with the other files if I open them with a text editor.

Here are the files in question if you're interested to have a look sometime:

https://www.dropbox.com/s/xzejd03ag1zm8a1/OpusTagError.zip?dl=1

Thanks,

TW

After further investigation of the files in a modified debug build of the plugin I discovered that my initial assessment of the integrity of the files' structure was wrong, very wrong. I found that further down in the files there were severe errors in the OggS page layout, namely, it looks as though either multiple sections of the files are missing OR the original encoder (lavf) overwrote key OggS page headers by mistake. These errors run the entire length of the files intermittently and are not recoverable.

If you obtained these files from online, try re-downloading them. If you converted them yourself, please please please please please use a different converter.

[thinktink]

Great, thank you! No rush.

I dropped a debug build of the plugin in Winamp and checked it out. The libopus libraries themselves are reporting that the files have malformed headers (Error code -133 in the header definition.) It doesn't indicate why or how, just the error code. I opened the files in my hex editor and saw that the OggS pages seemed to be formatted correctly so it must be in the file container payload somewhere. I haven't looked yet in the payload but maybe sometime during the weekend.

[TimbreWolf]

I will check it out later.

Great, thank you! No rush.

[thinktink]

Hi thinktink,

I've been loading some opus files into Winamp today using your latest plugin version 2.0.10.22.

Most of them work great thanks. Though I've hit a couple where I can't get the tags to load into Winamp. They've been tagged in the same way as the other files which work (using AudioShell), and I can see the tags are present in the same way as with the other files if I open them with a text editor.

Here are the files in question if you're interested to have a look sometime:

https://www.dropbox.com/s/xzejd03ag1zm8a1/OpusTagError.zip?dl=1

Thanks,

TW

I will check it out later.

[TimbreWolf]

Hi thinktink,

I've been loading some opus files into Winamp today using your latest plugin version 2.0.10.22.

Most of them work great thanks. Though I've hit a couple where I can't get the tags to load into Winamp. They've been tagged in the same way as the other files which work (using AudioShell), and I can see the tags are present in the same way as with the other files if I open them with a text editor.

Here are the files in question if you're interested to have a look sometime:

https://www.dropbox.com/s/xzejd03ag1zm8a1/OpusTagError.zip?dl=1

Thanks,

TW

[Omega X]

Looks like YouTube is now using Opus

YouTube has been using Opus for years now and very few noticed.

[papahuge]

Looks like YouTube is now using Opus

[thinktink]

Hello, please don't waste your time for me on that, 'cause actually we found out that this server implementation has many other issues, and we adapted a self-mantained streaming server (distreamer) to work with OGG streams and ICY metadata together.

...

It's been a while since I looked at that stream, and yeah, it padded in between the OGG pages with seemingly random data when you requested ICY metadata. Odd. For the latency, I don't know if I can fix that since ICY metadata runs at it's own interval but I'll look.

[AleRinaldi]

It seems that your server is sending the title info out-of-band as I can see no relevant metadata in the stream data itself. I'll have to record the raw bits later to investigate but so far that's what it looks like.

Hello, please don't waste your time for me on that, 'cause actually we found out that this server implementation has many other issues, and we adapted a self-mantained streaming server (distreamer) to work with OGG streams and ICY metadata together.

Now, the result is really good, except for a small issue: the metadata update isn't as fast and precise as with other media formats.
We put a timestamp on the end of the title and we use it on the other end to align playback between different locations and some other stuff.

If you try to play in Winamp http://vps.radioduepuntozero.it:7010/test.aac you can see the metadata is correctly updating (about) once per second, while playing the OPUS test stream at http://vps.radioduepuntozero.it:7000/test.opus the update doesn't have the same precision.

I know it's an uncommon use case, but if you could fix that we'd be finally ready to switch to OPUS on some internal streams and it would be a huge quality improvement

Thanks!

[thinktink]

It seems that your server is sending the title info out-of-band as I can see no relevant metadata in the stream data itself. I'll have to record the raw bits later to investigate but so far that's what it looks like.

[AleRinaldi]

Hello thinktink,
first of all, thank you very much for your great work: so far, this is the only way I found to play an OPUS Internet stream in Winamp. We are experimenting a lot with OPUS streams because their quality is waaay higher than MP3 or AAC+v2, expecially on lower bit rates.

We're finding out that, actually, streaming in OPUS is currently a mess, expecially when it comes to embedding titles in the stream. We tried with ShoutCast (titles pass but no sound), Icecast (sound passes but no titles), and finally we found out that MB Recaster (even the free edition) has an embedded streaming server that, wow, correctly handles both audio and titles! In fact, in VLC I can happily see the titles. Unfortunately they don't show up in Winamp with your plugin, even checking the "Require ICY" option.

Would it be possible for you to have a look on it? On http://regia.radioduepuntozero.it:8090/test.opus I'm hosting a test stream from our radio station: if you open it in VLC you see titles passing in the title bar, but this doesn't happen in Winamp.

Thank you very much!

[imperia]

I can't test it right now but send me a link to the server in a PM and I'll have a look when I get off work if I can.

I fixed it. I was mistake on my end. I was using my public address from my home network