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

[thinktink]

lol, this is what happens when you get bored thinking; or you get thinking bored.

Anyways, attached 48 hours of extremely high-fidelity silence encoded to Opus in a zip file.

The neat thing is, the file itself is 8,663 KB but compressed to zip (with 7z) it's only 1.388 KB.

[DrO]

post updated.

[thinktink]

it's the same thing so that saves me some time, just couldn't remember if it had already been mentioned or not.

I've updated the post to provide all of the other options which are present as of the current 5.666 (i doubt there'll be any changes to such things for 6.x but you never know).

OmNomNom thanks!

However, it looks like the new notes need adjustment as some of the config items don't work unless you ::GetUnsigned() instead of ::GetInt(). Trying to GetInt() doesn't work on certain ones. Had to investigate those by trial-and-error under the debugger.

"bits" == GetUnsigned();
"replaygain_source" == GetUnsigned();
"replaygain_mode" == GetUnsigned();

I also noticed ::GetType() didn't work at all although I suspect because the global option types will never change and therefore would be hardcoded to a type with prexisting type knowledge for each one.

Anyways, good to know I don't have to recode to the correct API method to get the global config stuff.

[DrO]

I found this thread:

http://forums.winamp.com/showthread.php?t=275371

Implementing it now, or at least most of it. ReplayGain is all done, but I want to see if I can also get in the Force Mono, 24bit (not likely), and Allow Surround parameters as well before pushing out.

If yours is easier though then I will incorporate it afterwards.

it's the same thing so that saves me some time, just couldn't remember if it had already been mentioned or not.

I've updated the post to provide all of the other options which are present as of the current 5.666 (i doubt there'll be any changes to such things for 6.x but you never know).

[thinktink]

New Version

Version 1.6.32.131 available.

• Added full support for Winamp's native ReplayGain functions (foobar2000 failzorz lulz).
• Disabled R128_* processing to ensure full compatibility with Winamp's native ReplayGain support.
• Integrated Winamp's ReplayGain configuration control.
• Integrated Winamp's dither configuration control.
• Integrated Winamp's playback thread priority configuration control.
• Added file's average bitrate to the format information in the UFIP editor.
• Added file's output gain header to the format information in the UFIP editor.
• Added ability to change the file's output gain header information ("Gain" button on the "Advanced" tab, please don't mess with it unless you are the person that encoded the file.)
• Added ability (from the configuration window) to disable the output gain adjustment on the decoder (playback) and the transcoder functions. It's use is not recommended, it's for advanced users only.

Download

[EDIT/]
Ack! About half the time I forget something.

The installer includes libopusfile 0.6 as before but replaces libopus with version v1.1-138-g8dc91de that I built with MSVC locally that incorporates a number of fixes, adjustments, and functionality additions, one of which is a bug for the encoder. When the new release of the libopus(file) get's pushed you can replace the old libraries and the changes will hold.

[thinktink]

nudge me about this next week (should be a in position to check that side of things for you then).

I found this thread:

http://forums.winamp.com/showthread.php?t=275371

Implementing it now, or at least most of it. ReplayGain is all done, but I want to see if I can also get in the Force Mono, 24bit (not likely), and Allow Surround parameters as well before pushing out.

If yours is easier though then I will incorporate it afterwards.

[thinktink]

The plugin doesn't seem to support ReplayGain as written by foobar2000 (global gain – album, R128_TRACK_GAIN metadata value – track, different scale). The album gain is correctly applied, if present, but plugin reports that the gain values aren't present, therefore Winamp applies the "adjustment for files without Replay Gain" (usually negative) in addition to it, leading to unusually low volume relative to music in other formats.

...

It appears as foobar2000 is fubar on handling gain adjustments and procedures on this one. For the time being, it might be a good idea to totally not rely on foobar2000 as a standard for behavior on Opus media. In fact, if you're looking for actual consistency of playback loudness, I'd stay away from foobar2000 concerning Opus files for a while. Very far away, at least for 3 years. Playing around with foobar2000 shows that its storing the R128 gain adjustment in the file header's OutputGain field, which overides the original encoder's arbitrary post-encoding level adjustment which has nothing to do with replay gain adjustments. The libopus library decoder automatically (by default) applies the header's output gain adjustment internally (not the player using the decoder) and if you think about it, foobar's behavior is very incorrect. Neither R128_* nor REPLAYGAIN_* should ever be put into the file's header gain adjustment field. Not ever. Well, if you're worried about or expecting cross-player interoperability/consistency. Just don't be surprised if you find everything whacked out when you transfer a foobar2000 R128 adjusted Opus file to another platform or player that's programmed to the intended Opus file specs. Yikes...

They're long reads but you kinda have to read most, if not all of it, to understand why.

http://comments.gmane.org/gmane.ietf.codec/19

http://permalink.gmane.org/gmane.ietf.codec/26

er, as Winamp doesn't support R128, it's probably better that it doesn't get told the values to use as you're then applying a value which is not correct for the replaygain option that Winamp uses. but that's just my thought on thnigs.

After doing a bit more research I believe your thought is correct.

[thinktink]

nudge me about this next week (should be a in position to check that side of things for you then).

Thanks.

[DrO]

nudge me about this next week (should be a in position to check that side of things for you then).

[thinktink]

After finally figuring out what the hell a "Q8" value is (I was totally oblivious to the Fixed Point number format) I've got the op_set_gain_offset(...) finally working as one would expect. Basically, I've got a working debug version of the plugin applying Winamp's RG tags to output. Now I just need to find the API way to actively detect Winamp's RG settings, which I'm having difficulty doing at the moment.

[DrO]

i think this just shows why it's generally better to use a newer Winamp client as it makes certain things for plug-ins a lot better than what 2.x was able to do.

as i know why thinktink's plug-in needs to have such information at the stage that it does and is why i'm also thinking of changing things in 6.x so the Winamp version is provided directly to the plug-in instead of needing to do a SendMessage(WM_WA_IPC, IPC_GETVERSION) - as that saves some of the things plug-ins need to do on loading and the less messages sent, the better (is a micro-optimisation which makes things for the plug-in easier).

[PPeti66x]

It's dead end. Not worth for a time. But this fact is now known.
Many thanks for this great plugin.

[thinktink]

So I just poked it with a stick.

Wow, what a pain in the butt.

I found that Winamp 2.x won't recognize the version of the plugin struct with the Unicode support indicator. Even worse, the main window doesn't exist to be able to check the version code during the call to winampGetInModule2(...) or Init(...) so even if Winamp 2.x did recognize it the plugin still wouldn't work right and would be impossible (from a programatic compatibility with my current workflow) to check the version of Winamp from the API to know when to use certain function types.

It looks like it would require a complete rewrite and recode of a number of major internals to make it 2.x compatible. Unless I can think of something outside the normal API to make things demonstrably easier I don't think I'll be coding for 2.x compatibility.

[thinktink]

The best that I could do would be to test an old Winamp 2.x client on a Windows XP machine since my 98se machine died a while back. If it weren't for that death I'd still be developing on Win98se with the latest version of Winamp (if it were possible, which I doubt.)

However, I know I have a Winamp 2.x installer somewhere and wouldn't take much to poke it with the proverbial stick a little bit on an XP machine. However, even if it was a simple matter, there's no guarantee it would work on Win98se OS since I don't have Win98se anymore.

I don't think there's a compatibility issue with the precompiled Opus libraries (I could be wrong on that though) considering the different architectures it is purported to support and I would be more inclined to believe it is the plugin itself that is the issue on Winamp 2.x clients.

[PPeti66x]

I know. And opus support is resolved for these old systems (Xmplay for Windows, Mpxplay for DOS). But sometimes for backward compatibility is enough to correctly select the target OS or use the older compiler (without changing the source code). If the original code was not written to be compatible with these old systems, then it is impossible to made compatible for reasonable amount of time. Without source code i can not check this.