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

[MrSinatra]

[thinktink]

k, I'm about to get hot-and-heavy into updating my disk writer plugin for Unicode support. So if there are any issues or feature requests you want me to address, please do not procrastinate.

I'm hoping this will be the last update I need to do for a while on this plugin, unless I missed something.

[Omega X]

Thanks for the fix thinktink.

Now I just need to figure out how WA and Fb2k does bitrate calculation for figure out why some Opus tracks get up to 400kbps in WA vs Fb2k.

[MrSinatra]

can u post some example files?

[Omega X]

I think its just the intervals at which both update VBR display. I jacked up the VBR refresh in fb2k and it showed me similar rates.

[MrSinatra]

that's interesting tho, b/c if the kbps is off by that much it might be a winamp bug, not just an opus one. I didn't realize the kbps was a matter of ticker display refresh rate, I thought it was either real time or a calculated avg via some time set standard.

[Omega X]

Fb2k does it in updates per second. Default is 2. I set it to 10. Its interesting to see how many times per second that the rate changes. Sometimes it holds the rate for a second or two. Based on that, it seems that WA only updates it once a second.

[Aminifu]

I do not know if it applies to this, but there is a timers resolution control for modern skins. It's on the General Preferences - Skins - Modern Skins - General tab. You can set a value manually or let Winamp set an optimum value based on your hardware.

[DrO]

the bitrate / kbps update is a core update and just uses what the input plug-in provides. for modern skins the update can take a bit longer to propagate to the ui due to how they work (being layered on top of the core messaging) and what else might be going on (so the modern skin timer resolution may have a small effect but it won't alter the fundamental time in the Winamp core itself). and how often the information is updated by the plug-in is down to the individual plug-in. finally, the skin itself can determine how often the information is updated on the display (is just classic skins where it follows the core times).

so everything sounds like its working as expected.

[thinktink]

The following is literally my code for showing the bitrate (minus the commented out stuff):

PHP Code:

        int tbr=Opus.op_bitrate_instant(curppl->oof);
        if(tbr>=0)
        {
                tbr/=1000;
                {
                        thisPlugin.SetInfo(tbr,-1,-1,1);
                }
        } 


[DrO]

seems fine to me.

[thinktink]

I'm thinking the difference might be down to fb2k not updating their handler to the latest Opus code release. Or it could be I'm using the instant bitrate at time of decode and they're using the bitrate for the entire file (or the entire link in a "possibly chained stream", yuk.)


From opusfile.h:

PHP Code:

/**Computes the bitrate for a given link in a (possibly chained) Ogg Opus
    stream.
   The stream must be seekable to compute the bitrate.
   For unseekable streams, use op_bitrate_instant() to get periodic estimates.
   \param _of The \c OggOpusFile from which to retrieve the bitrate.
   \param _li The index of the link whose bitrate should be computed.
              USe a negative number to get the bitrate of the whole stream.
   \return The bitrate on success, or a negative value on error.
   \retval #OP_EINVAL The stream was only partially open, the stream was not
                       seekable, or \a _li was larger than the number of
                       links.*/
opus_int32 op_bitrate(const OggOpusFile *_of,int _li) OP_ARG_NONNULL(1);

/**Compute the instantaneous bitrate, measured as the ratio of bits to playable
    samples decoded since a) the last call to op_bitrate_instant(), b) the last
    seek, or c) the start of playback, whichever was most recent.
   This will spike somewhat after a seek or at the start/end of a chain
    boundary, as pre-skip, pre-roll, and end-trimming causes samples to be
    decoded but not played.
   \param _of The \c OggOpusFile from which to retrieve the bitrate.
   \return The bitrate, in bits per second, or a negative value on error.
   \retval #OP_FALSE  No data has been decoded since any of the events
                       described above.
   \retval #OP_EINVAL The stream was only partially open.*/
opus_int32 op_bitrate_instant(OggOpusFile *_of) OP_ARG_NONNULL(1); 


Or I guess it's possible they're calculating it themselves instead of relying on the OpusFile API.

[DrO]

i wouldn't worry about it since the two players do things so differently on the implementation side of things that it's not at all surprising that what's shown at a specific time is not going to match up (as there are so many things which can lead to differences that it's not going to match if working with vbr files due to their nature).

[Omega X]

I have another low priority bug.

STR:

1. Note the Encoder tag on an Opus file in an external reader like MP3tag.

2. Edit file tag in Winamp.

3. Note the Encoder tag is duplicated.

For example, the encoder tag would look like this:

<Encoder> opusenc from opus-tools v0.1.8 SSE2 [2014-04-13]

After the edit in Winamp it looks like this:
<Encoder> opusenc from opus-tools v0.1.8 SSE2 [2014-04-13]
<Encoder> opusenc from opus-tools v0.1.8 SSE2 [2014-04-13]


This was also confirmed by opusinfo. The tag is generated a second time.

As an aside, I also get "Encoded with BogProg Support for Opus". But I guess its just displayed what wrote the tags last.

[thinktink]

Is this after creating an Opus file with the Winamp transcoder functions?

[EDIT/]
Go ahead and attach the Opus file so I can poke it with my hex editor.

[EDIT2/]
Nevermind, I've just replicated the issue with a new file made with the opus tools encoder. I'll poke at it for a while to see what comes up.

[EDIT3/]
Wait a minute, I was able to replicate the Encoder tag duplication but not the vendor marker overwrite. Something's up. Please send me that file.

[Koopa]

Just a short info, I've added detection of the opus lib files to the Info Tool reports. (take a look at the attached image)

Maybe this will be helpful for you in future, so you can see if all required libraries are present on the system.

-Chris

[thinktink]

Still waiting for a file that shows the behavior.

Originally Posted by Koopa

...

Maybe this will be helpful for you in future, so you can see if all required libraries are present on the system.

...

Very probably. I think there's been one instance of a dependency related problem. Don't remember.

[Omega X]

Ok, here's the file you asked for.

vBulletin's attachment script keeps failing, so here's a direct link:
https://drive.google.com/file/d/0B0K...it?usp=sharing

Up for a limited time.

[thinktink]

Originally Posted by Omega X

...

Up for a limited time.

Retrieved. You can take it off now. I'll have a look at it tomorrow morning.

[thinktink]

Can you attached an archive containing the exact tools or point me to a download link for the actual tools you used to create the opus files? I had received a problem file from somebody before that would explain the current behavior and I have a suspicion that the tools are in the wrong.

[thinktink]

Originally Posted by http://wiki.xiph.org/OggOpus#Comment_Header

...
* Vendor string (always present).
...

The next version will disable writing of metadata in files with malformed comment headers (tags.)

This won't fix the "ENCODER" duplication bug (which I've now fixed in an internal build) but I believe it will prevent the other bug causing the plugin to create the default vendor string as a place-holder for missing information during the metadata writes.

[Omega X]

Originally Posted by thinktink

Can you attached an archive containing the exact tools or point me to a download link for the actual tools you used to create the opus files? I had received a problem file from somebody before that would explain the current behavior and I have a suspicion that the tools are in the wrong.

http://sourceforge.net/projects/lame...29/2014-05-04/

[thinktink]

Originally Posted by Omega X

http://sourceforge.net/projects/lame...29/2014-05-04/

That doesn't seem to be the one. I'm getting a different encoder string from that one than from the file you provided:



The file you said had the bug:

opusenc from opus-tools v0.1.8-SSE2

LameXP that you linked:

opusenc from opus-tools v0.1.8 SSE2 [2014-04-13]

Can you instead send me an opus file after encoding but BEFORE editing it in Winamp?

Screenshots of the differences in ENCODER tags as viewed from hex editor attached.

[Omega X]

It might have been a previous version. The only other tools I have for Opus are the official command line tools from the Opus website. http://www.opus-codec.org/

I've uploaded an untouched file from both tools for comparison.
https://drive.google.com/file/d/0B0K...1PdkUyaG8/edit

I didn't know about the vendor string spec, that''s good to know.

[thinktink]

Originally Posted by Omega X

...

I've uploaded an untouched file from both tools for comparison.
https://drive.google.com/file/d/0B0K...1PdkUyaG8/edit

...

I just dropped those two files into Winamp with the latest published version of the plugin installed and it did not overwrite the vendor string. However, it did duplicate the encoder tag but I've resolved that in the next version.

P.S.
You can remove the archive now if you wish.

[thinktink]

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

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

Updates:

• Fixes encoder tag duplication on tag/metadata writes.
• Skips writing new tags/metadata to files with malformed (missing) vendor string.
• Encoder: Now includes libresample-0.1.3 so audio can be directly transcoded/ripped into the Opus format without needing to save to an intermediary file first for resampling to 48KHz. Doesn't invoke the resampler if input is already at 48KHz

WARNING:
As listed above, the included encoder now uses the libresample-0.1.3 library to resample incoming audio data not at 48KHz (which is required for the Opus audio codec.) If you care about quality at all then please take note. Compared to other commercially available and GPL licensed resamplers, this isn't the best resampler (not the worst though.) I'm using this resampler for two reasons; it compiles under Borland C++ Builder 5 Pro and it's LGPL (no socialist hacker manifesto licensing requirements.) I will be looking into replacing it with the SoX resampling library, but not today.


Note:
When I tested the new download link I noticed I had to force refresh the page for the new download link to show up. If you can't download the new installer package it probably means you need to purge your browser cache.

[thinktink]

I've seen a couple download hits on the latest version. Anybody having audio quality issues with the encoder?

[kzuse]

I downloaded the newest version because I regularly check here and use the newest one always, but I don't use the encoder at all...

But if I find some time later or this weekend, I'll give it a try and test with different sample rates and test signals (e.g. sine sweeps which can be used to test aliasing and imaging frequency and similar effects).

[thinktink]

While doing some testing on the encoder for speed, buffer utilization optimizations, and libsoxr integration, I discovered that the latest published version of the compiled opus libraries (v1.1) are failing on the encoding of multi-stream encodes under the hard CBR setting, which includes the uncoupled stereo channels mode. To get that very specific functionality back you'll have to download and replace the v1.1 libraries with a previous version. I would recommend the v1.1-beta builds if you can find them online somewhere or v1.0.1 if you don't like Betas. The latest version of the plugin will cope just fine with most, if not all, previous versions of the libopusfile libraries so no worries with using previous versions of the libopusfile libraries.

[MrSinatra]

wow, the devs over there must be impressed with your bug finding.

[thinktink]

Originally Posted by MrSinatra

wow, the devs over there must be impressed with your bug finding.

Not really. I rarely contact them because I don't wanna be a pest and I generally don't have problems with the codec except when I miss-conceptualize the API or theory of operation. This is the first time I've encountered what currently seems to be an actual flaw in their compiled binaries. I haven't gotten any word back from them yet on the issue.

[Omega X]

I don't think they mind. Interest in Opus is kind of flat currently. A lot of software picked up on it early and most of their releases have been pretty solid.

[thinktink]

At this point they still believe it's my fault but I've narrowed down the issue to multistream hard cbr with bitrates of Auto, Max, and below certain values depending on the number of channels.


Again, all previous versions of libopus and libopusfile work fine in all modes.

[MrSinatra]

I've noticed that it can take a lot to convince devs of anything!

[thinktink]

Originally Posted by MrSinatra

I've noticed that it can take a lot to convince devs of anything!

That's not always true though. I know DrO, Koopa, DJ Egg and some others from the Winamp dev team are above-par reasonable. More so than myself sometimes.

[MrSinatra]

I totally agree, was just ribbing a bit.

[thinktink]

I'm still on it like a duck on a June bug. Created a Trac ticket that shows it also happens on the compiled encoder tools and not just my Winamp encoder plugin.
http://trac.xiph.org/ticket/2027

[thinktink]

New version 1.5.27.100 (with encoder version 1.3.5.11) now available for download.
Download

Let's see if I can remember all the changes from memory...

• Added "Advanced" tab in the Unified File Information Pane so that now all vorbis tags (except "ENCODER" and "METADATA_BLOCK_PICTURE") are editable. That was a pain in the ***...
• When libsoxr.dll is present (included in installer) in Winamp folder the encoder uses it instead of the lower quality internal one.
• Massive encoder plugin update to reducing encoding time.
• Fixed encoder container segment formation algorithm logic errors for certain rare segment lengths.
• Added frame size (in milliseconds) option to encoder.

[EDIT/]
Note: The encoder error from http://trac.xiph.org/ticket/2027 is still valid but the encoder plugin itself is still functioning correctly (verified with a previous build of libopusfile.) After investigating their source I saw that it's an internal problem with their code. Not much I can do about it. However, all of the other modes seem unaffected. If/when they release a fix for the error you can replace the faulty libraries with their new ones by manually replacing the old dlls in the Winamp\opusfile sub-folder with the new ones.

[Koopa]

Hey thinktink,

an advanced tag editor is really a nice addition. Keep up your good work.

I sadly have to report 2 issues, I had when I'm using your new version:

1. The alt+3 dialog hangs for me:

http://www.meggamusic.co.uk/shup/1402440646/opus.png

2. Using the 1.3.5.11 encoder produces a crash, as soon as i try to convert e.g. an MP3 file to Opus (with the Winamp transcoder). I just installed previous version of the plug-in and then the encoder doesn't crash:

http://www.meggamusic.co.uk/shup/1402440748/report.zip

If I can help you with testing etc or if you need additional info, just lemme know.

[thinktink]

Ok, that's just weird. I can't think of anything specific with the new code that could cause issues like that so fast. From the txt report it seems like it's something in the metadata handling though you telling me that it happens as soon as you try to encode something that it crashes (instead of after encoding metadata during the transfer).

As an experiment, keep the previous version of in_bpopus but install the new version of enc_bpopus and see what it does. Then do new version of in_bpopus and old version of enc_bpopus and see what happens there.