This may be a stupid question, but how would I use that version? I know nothing about compiling opusenc or anything else for that matter.The command line Opus-tools only goes up to libopus 1.0.2 in opusenc.If I get alpha 1.1 to work and I still have problem samples I will put them in a new topic.
Hi,Thanks for these links. The one in the opus testing topic is working just fine. I'll go reporting there.
Okay will do. It seems that the alpha works better for the tonal samples, and is using a more unconstrained VBR? Because on the samples I tested which had problems with 1.0.2, the alpha 1.1 did much better with a substantial increase in bitrate. The test I did was targetted at 64kbps, and 1.0.2 gave a bitrate of 65, while 1.1 gave one of around 86 I think. If I forced CBR on both versions, 1.0.2 had more distortion in the low end and 1.1 fixed that, but introduced a bit more on the mids and highs which I find more agreeable, since it still beats the griddy sound of SBR in my opinion. I have yet to find a sample that really trips the alpha at a reasonable bitrate like the previous version did, but I will be sure to let you know if I do.
And another interesting thought. Could the research that went into developing Opus be used to refine a codec like Vorbis which is only for storage? Maybe some new coding strategies based on Celt but something which works well in high delay situations. I know Opus is great for storage as is, and was intended to be so, but if low delay codecs are at so much of a disadvantage, then it would make sense to wonder what something like Opus could do without that restriction. It's probably impractical at least for now but it's an interesting thought.
I think that would be interesting to know, too. Would Opus be actually more efficient with the option of bigger framesizes, or just a trade off with the handling of pre-echos vs. tonality? Jmvalin, you told that the specialisation on the little framesizes is too deep to just confer the techniques inside on something like a theoretical successor of Vorbis. Does that mean that there's not much room for improvement on a new high delay codec over Vorbis with the recent technology?
The quality versus latency tradeoff at 64 kbps for 20ms frames seems to indicate that 10ms frames require about 10% higher bitrate, 5ms frames need about 32.5% higher bitrate and 2.5ms frames need 75% higher bitrate for same PEAQ score. This limited data set makes it look as though we're approaching an asymptote of marginal gains and the bitrate reduction is going to be pretty small for typical signals if we move to 40ms. However, it's plausible that the long-frame efficiency would be greater for highly tonal signals or signals with multiple tones at the same time. Is the advantage worth it given the typical nature of music?I expect some of the people like Jean-Marc and NullC can add experience to confirm or contradict this.
Right now, there's scope for an offline mode in Opus, where music detection when not live streaming can be modified, for example, to check more carefully the few seconds before the existing detector activates, perhaps with a longer FFT to detect lower frequency tones that would get missed by the short lookahead of the current, live mode.
There are other ideas for a few years down the line that are being modelled. Some of the Xiph Ghost ideas, like separating tonal from transient parts of the signal and encoding them separately in their most efficient manner, require a lot of processing from today's CPUs, but might be viable in a few years if they can be made to work well enough, and might be a better use of developers time, as NullC said (Monty's sinusoidal modelling).
Quote from: Dynamic on 07 May, 2013, 02:44:14 PMRight now, there's scope for an offline mode in Opus, where music detection when not live streaming can be modified, for example, to check more carefully the few seconds before the existing detector activates, perhaps with a longer FFT to detect lower frequency tones that would get missed by the short lookahead of the current, live mode.This is already implemented in git, though opus-tools does not support it out-of-the-box yet (it's an experimental branch).
As nobody more authoritative has replied... No, I don't think it's implemented in the test builds we've seen here.For limited public testing of experimental builds, such as here, releases are a little less frequent than changes to the git (from which the devs may compile frequently) once a few major changes have been incorporated and are ready to be tested on a range of real world samples and different listeners.
In the recent experimental version thread someone reported that music detection activated only on the third note of a sample and this was because the first two tones were within the lowest frequency bin - a result of Opus's short transform windows thanks to its short frames (20ms), where low frequencies can look a lot like a DC signal. If you take a longer transform window (lasting more than 20ms), the frequency width of each bin is reduced commensurately and that's one way to detect the onset of music consisting of low frequencies but little high-end, though there are other options and I suspect the devs have worked on picking the optimal choice for this application and putting those fixes into the git repository ready for the next release.Any method I can think of to pick up this corner case pretty much demands more look-ahead, so this fix could only be made in offline mode, not interactive. Any other fixes to problems found in that experimental version will also be addressed in git if possible before a future experimental version is put up incorporating those fixes and asking for further serious testing.