Opus-Tools 0.1.6? There's just 0.1.5 on the official site.
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.
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.
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.
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,
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.
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
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?
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.
QuoteHere'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.
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.
QuoteFor 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.
Most of that time was R&D work, not engineering production time
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.
Quote from: NullC on 11 December, 2012, 01:31:31 PMQuoteHere'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.I was just saying these are possible reasons. If these don't help diagnose the problem, fine; let's find a better diagnosis.
@saratoga: Your advice might be true, but definitely does not solve the problem.
@NullC: Do you need to re-read the three clauses of the BSD License, in which you are distributing the specification, the reference implementation and the "revised implementation"? (whatever that is)
What exactly is the problem are you expecting me to solve?
Why would someone need to re-read the BSD license exactly? This question doesn't really make sense.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:...Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
That's why I ended the post saying that If he's open to talk about it, we might find a common point that we can both agree. As it is, it gives a bad looking for an open source project to limit what you can do with the source (more so being BSD license, not GPL).
.\opusenc -Vopusenc opus-tools (using libopus unknown)Copyright (C) 2008-2012 Xiph.Org Foundation
Oops! Re-compiled and uploaded on same link with version strings corrected.
In order to get this to compile, it's necessary to disable all of 'resample_sse.h' except the xmmintrin.h include, otherwise the compiler throws errors.
Quote from: john33 on 13 December, 2012, 07:22:07 AMIn order to get this to compile, it's necessary to disable all of 'resample_sse.h' except the xmmintrin.h include, otherwise the compiler throws errors.IIRC this was fixed in Speex code: http://git.xiph.org/?p=speex.git;a=commitd...3919fd272fc9f74