IPB

Welcome Guest ( Log In | Register )

Please update opus-tools binaries at Rarewares
Dukers
post Dec 11 2012, 11:17
Post #1





Group: Members
Posts: 22
Joined: 29-July 07
Member No.: 45724



Please update opus-tools with version 0.1.6/libopus 1.0.2. If possible backport flac input support added in commit 892fd929 just after 0.1.6.

http://rarewares.org/opus.php
Go to the top of the page
+Quote Post
 
Start new topic
Replies
NullC
post Dec 11 2012, 15:22
Post #2





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



The FLAC support isn't released yet because its brand new, hardly tested code. I'd really prefer people not continue publishing pre-releases on the web where the people downloading them will have no idea where to contact the developers, won't necessarily expect the software not to eat their babies, etc.

There will be releases with flac support within a couple weeks.
Go to the top of the page
+Quote Post
jensend
post Dec 11 2012, 18:52
Post #3





Group: Members
Posts: 140
Joined: 21-May 05
Member No.: 22191



QUOTE (NullC @ Dec 11 2012, 07:22) *
I'd really prefer people not continue publishing pre-releases on the web where the people downloading them will have no idea where to contact the developers, won't necessarily expect the software not to eat their babies, etc.
I can certainly understand the concern that too many people are using bleeding-edge git snapshots compiled by random guys from the forums rather than using stable releases from solidly-trusted sources. That's only appropriate for people who are willing to deal with git breakage and get seriously involved in the testing/development process. To avoid headaches it'd be much better for people who expect the software to "just work" to be using stable binaries compiled by people who are absolutely sure to know what they're doing. It'd also help if people who are willing to get casually involved in the testing/feedback process were using better-trusted binaries.

But telling other people not to post prerelease binaries is not the way to fix this problem. Every open-source project has the potential for this kind of problem, but almost all of them successfully avoid it without trying to discourage people from building and distributing their software. Why is it that Opus has this problem while others don't?

Here's some possible reasons: you've neglected official binaries, you've undersold the stable versions, and you've stopped releasing early and releasing often.

The binaries linked from opus-codec.org predate the 1.0 release. This doesn't just mean that people who download from there are missing out on a fair number of bugfixes and a few improvements; it also means people will abandon using trusted sources for binaries. And many of the other sources which are distributing binaries are distributing git snapshots and/or "optimized" binaries that are actually slower than the gcc compile.

For the better part of a year people at HA and elsewhere have been told that the stable version is mediocre at music but exp/master is much better. While it's true that if the settings are held constant the development branch gives better encodes of tonal samples, it's still unclear how much improvement there is when it's constrained to give the same average bitrate over a large collection of music. I trust that the continuing refinements and fixes will make the final 1.1 release a substantial improvement. But in the meantime 1.0.x is not as bad as it's made out to be - a few trained listeners managing to ABX something doesn't necessarily mean a broad part of the populace at large will give it a low MOS - and there are substantial benefits to using a known-good stable version with predictable behavior. For instance, in one somewhat recent development build I found there are bitrates where the mode switching kinda thrashes around on speech input, and it's very distracting to have the bandwidth and character of your audio changing like that, especially in an audiobook. (From commit messages I suspect that may have been fixed since then, but I haven't tested much.) I'm also not convinced that the development version's attempt to provide higher bandwidth at lower bitrates than the stable version while in LP/hybrid modes is well-tuned yet even when it doesn't thrash around.

During earlier phases of development, I suspect most of the people who were distributing binaries to those willing to get casually involved in testing Opus were distributing development releases, which happened about once a month, and not random git tags. Only those who were actually ready to deal with git breakage were using the bleeding edge. But your development branch has now seen 9 months of vigorous development without releasing a single alpha or even just choosing appropriate snapshots to distribute. Anyone who's casually interested in trying out the hyped improvements is going to end up using some random guy's random git snapshot build.

If opus-codec.org provided up-to-date stable binaries, alpha source releases, and some kind of very visible recommendation about who should be using what, I think that would start to address the problem much more effectively. The reason that major open source projects don't usually have tremendous support hassles with naive users using random "OMG 0PT1M!Z3D!!!1" builds and random git snapshots isn't that such builds don't exist (au contraire!) or that they tell people to quit visibly publishing them, it's because the official releases handily outcompete such builds. They are better-publicized, better-trusted, bring users improvements on an appropriate schedule (freshly-baked rather than half-baked or stale), and generally deliver a better user experience.
Go to the top of the page
+Quote Post
NullC
post Dec 11 2012, 19:31
Post #4





Group: Developer
Posts: 200
Joined: 8-July 03
Member No.: 7653



QUOTE (jensend @ Dec 11 2012, 10:52) *
But telling other people not to post prerelease binaries is not the way to fix this problem. Every open-source project has the potential for this kind of problem, but almost all of them successfully avoid it without trying to discourage people from building and distributing their software. Why is it that Opus has this problem while others don't?
I can simply stop posting code in public which I don't believe is ready for consumption by non developers. Is this the outcome you want? I don't mean to say that in a threatening way but it will be the natural outcome of the approach you're taking with me. Many projects develop with a model where things just appear when complete. It has its advantages and disadvantages.

If people who casually want to help need binaries— we're available almost all the time via IRC and email. Finding out that someone is posting binaries in yet another thread that I've missed on HA after someone shows up with some weird files complaining about bugs that never made it into a release is just really unwelcome. It's frustrating, it slows development, and it shifts the balance towards not posting code until things are complete and tested.

QUOTE
Here's some possible reasons: you've neglected official binaries, you've undersold the stable versions, and you've stopped releasing early and releasing often.
These claims are simply untrue. The binaries have not been neglected, the only binaries available from the site are the stable ones so its hard for me to find support for your undersold claims, and we are not behind our historic release cadence especially considering in the past we were developing the format, and now the format is complete and there have been far fewer reasons to cut releases.

People shouldn't expect releases more than a couple times per year. If they're interested in participating in development (e.g. by testing current development work) then I welcome them to start building their own from git (knowing what they'll get) or hopping on IRC and asking for binaries if they're unable to build themselves. The only thing I'm unhappy about is random development versions, often with incorrect versioning information, being promoted on HA as "the thing to use" to people who aren't interested in participating in the development, especially when that promotion is happening absent any objective testing results which shows them to be better.

QUOTE
This doesn't just mean that people who download from there are missing out on a fair number of bugfixes and a few improvements; it also means people will abandon using trusted sources for binaries. And many of the other sources which are distributing binaries are distributing git snapshots and/or "optimized" binaries that are actually slower than the gcc compile.
There are not missing out on a "fair number of bugfixes and improvements"— The 1.0 opus library itself was not functionally changed for 1.0. They are missing some build system tweaks which are irrelevant for the binaries and a version string.

And yes, I tagged opus-tools 0.1.6 on Saturday knowing that we probably wouldn't have binaries up until mid week. Normally I prefer that the source release predates binaries a little bit simply to get a slow roll deployment, but in this case tagging 0.1.6 also was delaying merging flac (since it wasn't worth the extra confusion of branching for it). I thought this was a good decision, but I now regret it because you're accusing me of "neglecting the official binaries" as a result.

QUOTE
For the better part of a year people at HA and elsewhere have been told that the stable version is mediocre at music but exp/master is much better.
I have responded this specifically to people complaining about surprisingly poor results on highly tonal samples, including people who weren't even trying to do critical listening (at least at lower rates). The issues are not some subtle ABX thing requiring trained listeners— in the prior HA 64k listening test _every_ listener slammed the couple really tonal samples. People get asked to use exp_analysis branches when they're doing comparisons and complaining about tonal samples because further reports of issues there simple aren't informative.

QUOTE
and there are substantial benefits to using a known-good stable version with predictable behavior. For instance, in one somewhat recent development build I found there are bitrates where the mode switching kinda thrashes around on speech input,
Yes, and we don't post binaries of development versions for that reason. I hand out one off builds to people who are actually reporting behavior and ask them for results. I don't want people who aren't paying attention ending up with the experimental stuff, especially if they don't have an established channel to report issues they find with it. And yet you seem to be yelling at me here for asking other people not to do it either.

QUOTE
Only those who were actually ready to deal with git breakage were using the bleeding edge. But your development branch has now seen 9 months of vigorous development without releasing a single alpha or ev1en just choosing appropriate snapshots to distribute.
Most of that time was R&D work, not engineering production time... and concurrently the stable branches have been developing and maturing. There will probably be a 1.1 alpha in the next week or two. You might as well say that we had 3 years of development without a release since we've certainly had things take that long between research and publication.

QUOTE
If opus-codec.org provided up-to-date stable binaries, alpha source releases, and some kind of very visible recommendation about who should be using what, I think that would start to address the problem much more effectively. The reason that major open source projects don't usually have tremendous support hassles with naive users using random "OMG 0PT1M!Z3D!!!1" builds
The website _does_ and we haven't generally had problems with it outside of hydrogen audio, or even too much of one on HA. HA has the additional problem that newest posts bump the threads, so unless there is a new release every day it can't hope to consistently out-compete people posting.

This post has been edited by NullC: Dec 11 2012, 19:56
Go to the top of the page
+Quote Post

Posts in this topic
- Dukers   Please update opus-tools binaries at Rarewares   Dec 11 2012, 11:17
- - Gainless   Opus-Tools 0.1.6? There's just 0.1.5 on the of...   Dec 11 2012, 12:29
|- - Nekit1234007   QUOTE (Gainless @ Dec 11 2012, 15:29) Opu...   Dec 11 2012, 12:30
- - Gainless   Would be good to have this as a package in the off...   Dec 11 2012, 12:36
- - john33   I'll try to get this done by the end of the we...   Dec 11 2012, 15:18
- - NullC   The FLAC support isn't released yet because it...   Dec 11 2012, 15:22
|- - jensend   QUOTE (NullC @ Dec 11 2012, 07:22) I...   Dec 11 2012, 18:52
|- - NullC   QUOTE (jensend @ Dec 11 2012, 10:52) But ...   Dec 11 2012, 19:31
|- - jensend   QUOTE (NullC @ Dec 11 2012, 11:31) I can ...   Dec 12 2012, 00:46
|- - saratoga   QUOTE (jensend @ Dec 11 2012, 19:46) QUOT...   Dec 12 2012, 01:41
- - Dukers   OK. No flac input for now. We can wait a couple of...   Dec 11 2012, 22:54
- - [JAZ]   @saratoga: Your advice might be true, but definite...   Dec 12 2012, 20:04
|- - saratoga   QUOTE ([JAZ] @ Dec 12 2012, 15:04...   Dec 12 2012, 20:26
|- - [JAZ]   QUOTE (saratoga @ Dec 12 2012, 20:26) Wha...   Dec 13 2012, 00:04
|- - DonP   QUOTE ([JAZ] @ Dec 12 2012, 18:04...   Dec 13 2012, 01:18
- - jensend   NullC isn't trying to tell people that they ha...   Dec 13 2012, 06:11
- - john33   Here is a build of Opus Tools 0.1.6. This is curre...   Dec 13 2012, 13:22
|- - Nekit1234007   john33, ahem… CODE.\opusenc -V opusenc opus-t...   Dec 13 2012, 13:35
|- - lvqcl   QUOTE (john33 @ Dec 13 2012, 16:22) In or...   Dec 13 2012, 16:10
|- - john33   QUOTE (lvqcl @ Dec 13 2012, 15:10) QUOTE ...   Dec 13 2012, 17:22
- - john33   Oops! Re-compiled and uploaded on same link wi...   Dec 13 2012, 15:05
|- - Nekit1234007   QUOTE (john33 @ Dec 13 2012, 18:05) Oops...   Dec 13 2012, 15:13
- - john33   I've just added an ICL12.1 Win32 SSE2 compile ...   Dec 13 2012, 18:29
- - Dukers   Thanks, john33.   Dec 13 2012, 23:52
- - Bostedclog   Please be gentle .But this latest opus release.D...   Dec 14 2012, 14:30


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th April 2014 - 23:19