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

[thinktink]

Does it still not work if you use http://71.123.219.245:8000/xrm.opus instead? (same server, just with the hostname already resolved to the IP address.)

[Kigen]

Running Winamp in compatibility mode (Windows XP SP3) does seem to fix the issue on Windows 8.1 Pro.

Edit: Worked once, then stopped. Curious.

And no, doing it directly via IP address doesn't seem to make a difference.

[Kigen]

Trying on my Windows 7 Pro x64 machine and its experiencing the same issue. Waiting for data, then disconnect.

[thinktink]

Aye, I'm seeing the same thing on Windows 7 64x Pro. Every great one-in-a-while it'll connect and stay connected. I checked my server logs to see if it's connecting and it is, complete with headers and everything. Odd. Very odd. Still looking into it.

[Kigen]

I've been able to get connect and stay connected by keep retrying. I am hearing audio problems during song transitions (presumably because of the metadata being sent). The server should be using ice headers and using OpusHead and OpusTags.

[Kaminari]

Experiencing the same issue (along with a complete freeze of Winamp) on Win7-64 Pro.

[thinktink]

Originally Posted by Kigen

... I am hearing audio problems during song transitions (presumably because of the metadata being sent). The server should be using ice headers and using OpusHead and OpusTags.

It's because the Opus specification says that each li in the chain doesn't have to be the same number of channels so I have to close and re-open the output plugin on every new chain. The metadata is not the issue, the stream is. The Opus developers have said that opus streams don't use icy metadata (though the plugin still supports it.) However, I'll look to see if I can keep the same output plugin session if the current chain has the same NCH as the previous.

Originally Posted by Kaminari

Experiencing the same issue (along with a complete freeze of Winamp) on Win7-64 Pro.

A complete freeze I've yet to see on Win7 64bit.

[Kigen]

That would make sense with the interruptions I'm hearing. Since Liquidsoap is setup to fade between songs/promos the close and reopening would cause such a disturbance.

[thinktink]

In an extremely debug build of the plugin I see that I'm getting the same data internally on WinXP 32bit and Win7 64bit but for some reason the code is not recognizing the data on Win7 64bit, which is really really really odd.

[thinktink]

Originally Posted by Kigen

...

http://radio.kigen.co:8000/xrm.opus

...

Just so you know, very very very very very very very very very very very bad "spambot" detection system:

[thinktink]

Update to the most recent problems:

It would seem I have corrected the issue on Win7/8 by removing what appears to be a couple of spurious auto critical section references in the stream handler thread. However, before posting the updated version I'm going to look-see if there's a quick and easy way to avoid closing and re-opening the output plugin on track changes in the online stream for tracks that don't change the number of channels between songs (this endeavor might be easier said than done with the nature of the codec.) Might take a while since your radio station has particularly over-long tracks.

[Kigen]

There isn't any spambot detection going on. That website is dead. But the way it was coded the spambots were able to get to the forums and spam it. So I added a die() earlier this year that said that. I've changed it around so you don't think the site thinks your a spambot. View it now. :P XRM is dead. The only reason the streams are going by that name is so we can test Steamcast, which just got a beta release (see sig).

Anyway, happy to hear you got the failure to connect problem figured out. I'll be waiting for the new version.

The songs should be avg 5 minutes.

http://radio.kigen.co:8000/view/3 - Song history

[thinktink]

Ok, see if the attached 1.3.21.69 version clears up the problems on Win7/8.

There MIGHT be a bug or two that slipped by because I didn't do any rigorous testing on the modifications to the non-channel change output plugin session preservation that I usually do. This version is mostly just to test the threading issues.

[Kigen]

Its definitely connecting correctly now. Good work.

[Kigen]

There was a significant delay (1-2 seconds) in audio during song transition. The audio is now not synchronized with the visualizer. Reconnecting obviously fixes.

Edit: Happens when a promo plays.

[thinktink]

k, looking into it.

[thinktink]

The attached 1.3.22.77 version should fix all that ails ya. I redesigned the handling of URL resource playback to use the libopusfile library callbacks instead of parsing the OggS packets myself. Net result of this is that all streams (and all linked Opus chains) will always be outchucked as stereo (even if the stream is mono or quadraphonic or 5.1 or whatever other numbers you throw at it), which means no closing and reoppening of the output plugin during link changes.

Unfortunately, this means that libopusurl support was dropped in favor of the callback versions. When the new version of libopusurl is finally published, I'll try to find some way to bash libopusurl support back into it with the new handler as the new fallback.

Tested on Win7 Pro 64bit and WinXP Home 32bit.

This is an official (well, about as official as I can make it) non-beta release build. Latest supported version.

[kzuse]

Originally Posted by thinktink

Unfortunately, this means that libopusurl support was dropped in favor of the callback versions.

What does that mean exactly? Does it affect any functionality, or is it merely some "beauty/simplicity of the code" thing?

And a second thing: If this is the latest non-beta-build, you might want to update the link in your signature to point to this post instead of the old one (which doesn't contain the attachment any more).

Thanks for all this and the continuing support of your Plugin!!!

[thinktink]

Originally Posted by kzuse

What does that mean exactly? Does it affect any functionality, or is it merely some "beauty/simplicity of the code" thing?

http://forums.winamp.com/showthread....25#post2966325

Originally Posted by kzuse

And a second thing: If this is the latest non-beta-build, you might want to update the link in your signature to point to this post instead of the old one (which doesn't contain the attachment any more).

Gah! I always forget...

[kzuse]

I still don't get it, what the difference is between the libopusurl and the "own handler" thing.... but I guess, it's all fine in the newest build

[kzuse]

But it seems that I don't need the following files then, am I right?:

libeay32.dll
libopusurl-0.dll
ssleay32.dll

[thinktink]

Originally Posted by kzuse

I still don't get it, what the difference is between the libopusurl and the "own handler" thing.... but I guess, it's all fine in the newest build

The liboupusurl API's include support for proxy connections, https, and seeking of online files. My handler does not. I've put off trying to implement any of that myself because I'm waiting/hoping for the JNetLib Wasabi APIs to be published by DrO though he has his hands full at the moment so it'll be a while before I know when/if I'll be able to implement those features myself.

And yes, that's what those libraries in the previous post you mentioned are for so you can remove them if you want but I don't recommend you do as the plugin might use some ancillary functions in them for efficiency purposes.

[EDIT/]
I'm about to re-focus my attention back to the issues with Skinimizer so if there are any additional issues with the plugin, let me know A.S.A.P. before I get heavy into Skinimizer.

[thinktink]

Originally Posted by myInbox

I'm pleased to announce the release of version 0.5 of Tim's opusfile
library for decoding and seeking inside .opus files and remote streams
over http(s). This release includes some new API calls and fixes a
number of mostly minor bugs from the previous release.

Programming documentation for this release is available from
http://opus-codec.org/docs/opusfile_api-0.5/

Changes since the last release:

- Report HTTP (ICY) headers to client
- New tag comparison and copy functions
- New application decoding callback API for advanced clients
- New dither disable function for advanced clients
- constify API
- Avoid clipping downmixing from a fixed-point decoder
- Better practices for dual stack IPv6
- Documentation improvements
- Fix a unicode bug on Windows
- Fix proxy user/password macros
- Fix HTTP pipelining support detection

Source is available from:

https://ftp.mozilla.org/pub/mozilla....ile-0.5.tar.gz
https://ftp.mozilla.org/pub/mozilla....usfile-0.5.zip
http://downloads.xiph.org/releases/o...ile-0.5.tar.gz
http://downloads.xiph.org/releases/o...usfile-0.5.zip

Windows binaries from:


https://ftp.mozilla.org/pub/mozilla....-0.5-win32.zip

SHA-256 checksums:

2ce52d006aeeec9f10260dbe3073c4636954a1ab19c82b8baafefe0180aa4a39
opusfile-0.5.tar.gz
b940d62beb15b5974764574b9f265481fe5b6ee16902fb705727546caf956261
opusfile-0.5.zip
93104cab67a2b038753d125028d63c0028a277e798f8ca88df73d4edbfb9a787
opusfile-0.5-win32.zip

Thanks to everyone who contributed!

-r

On it...

[Jay]

Something I have noticed:

Winamp seems to crash pretty indiscriminately when playing Opus with that plugin. It's a great plugin so far though. But it seems that whenever there is a new connection sometimes it crashes. Also if you tune into an Opus file/stream and then hold 'x' while winamp is active. The plugin will eventually crash. I think it has something to do with not locking resources.

[thinktink]

That's interesting. When it crashes on a new stream, does it just lock-up/hang or does it do a full crash/close? What operating system/skin does it occur on?

[Kigen]

I've also observed crashes when the stream is interrupted.

Windows 8.1 Pro x64 with on Winamp 5.666 Classic skin

[Jay]

Using classic skin, Windows 7 Pro.

I get a mix, sometimes it locks up and Winamp is simply unresponsive, other times I get the "Abnormal Program Operation" error. The easiest way to duplicate the problem is to hold 'x' while Winamp is active on an Opus file/stream.

[thinktink]

k, I was able to replicate the error on WinXP. It seems to be a problem with CRITICAL_SECTION object deletion when a playback thread has finished. Debugging shows that it's not owned by any thread of execution at the time of the exception (it's an OS generated exception) so I don't understand why the error. Either way, I think I've managed to suppress the error. The "fix" will ship out on the next release.

[Melkor]

I found a couple of bugs. They might not even be your fault. If you make an opus file that is really long, weird things happen.

1) The "File Info" window reports PCM Frames as if it were a 32bit signed integer. The number being fed to it is an unsigned number, so if you have more that 2^31 frames, the number appears negative. Also if you have more than 2^32 frames, it silently overflows, loosing track of the real number of frames (my 34 hour file is reported as being about 9 hours).
2) The Playlist window seems to have the same problem, however if PCM Frames (as reported in the File Info window) are negative, winamp won't show a duration. If the frame count exceeds 2^32 frames and the resulting overflowed value is less than 2^31, it displays a wrong duration. So my 15 hour file shows no duration.

That said, when playing the file, winamp is able to get the correct remaining tracktime and to seek properly.

I'll be splitting the files to avoid the whole 32bit overflow as it seems to bug Rockbox as well (which is what I use for playback).

[thinktink]

I'm still working on the new APIs so it'll take a little bit. Noted.

[ZavierQuixote]

I'm not seeing the newest version 1.3.22.77 update in your previous post. Is there another place where it can be downloaded?

[thinktink]

Originally Posted by ZavierQuixote

I'm not seeing the newest version 1.3.22.77 update in your previous post. Is there another place where it can be downloaded?

http://bogproghome.hopto.org/downloadwinampopus.html

[ZavierQuixote]

Thank you, thinktink! Excellent work, as usual!

[Opususer]

Thanks a lot for the plug-in, it generally works very well.
When I have your plug in installed and update my media library which only consists of opus files winamp crashes. I found out this only is the case if there is an opus file in the libary which has a LOT of text in the meta-field "comment". (At least I hope this is called "comment" in the english version of winamp and I hope you know what I mean with "meta-field") Could this cause some kind of overflow?
Please let me know if I can help any further to find the root cause to this issue.

BogProgOpus1_3_22_77
Winamp 5.666 Build 3516 (x86)
Windows 8.1 x64

[thinktink]

Originally Posted by Opususer

...update my media library which only consists of opus files winamp crashes.

Can you send me one of the files with the large comment metadata field that I can test with?

[Omega X]

Is it normal that calculating ReplayGain sends the percentage to 200%?

[MrSinatra]

200%? I see values in terms of db, how do u see percent?

[Omega X]

That's cute.

When RG is being calculated the window that shows progress pushes the percent to 200% instead of the usual 100% with other files. It also seems to take longer than with Winamp approved formats.

[MrSinatra]

wasn't trying to be cute, but now I understand. I'm sure TT will fix.

[thinktink]

Release (non-beta) version 1.4.23.80 is now available.

http://bogproghome.hopto.org/downloadwinampopus.html

Updates:

• Fixed crash issue with playback stops/track changes.
• Re-enabled support for libopusurl and included support for proxy connections from Winamp's specifiers.

Installer now includes the following support libraries from the opusfile-0.5-win32 package:

• libgcc_s_sjlj-1.dll

The old support files are also updated with new files from the aforementioned package.

I haven't had a chance to look into the very long file glitch or the RG glitch yet.

At the moment, I have a cold.