HydrogenAudio

Lossy Audio Compression => Opus => Topic started by: NullC on 2013-01-22 20:13:42

Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-01-22 20:13:42
I'm looking for suggested features to get into opus-tools prior to the libopus 1.1 release.

Before I get 1001 suggestions for it: One frequently requested feature which was recently added is flac input in opusenc. I'm contemplating changing opusdec to use the new opusfile library— which would give it seeking and integrated http(s) streaming support. Also already on my todo list are default comment packet padding so updating metadata doesn't require rewriting the files and adding a replaygain tool.

Some people would really like it if opusenc/opusdec supported taking multiple input files e.g.  opusenc *.flac  but the implicit output file naming is pretty ununixy, and would break the interface and I got flamed all to heck last time I changed the opusenc interface.... so I'm not sure if/how I want to accommodate that usage.

What other things have you found missing?
Title: What features would you like to see in opus-tools?
Post by: skamp on 2013-01-22 20:25:55
What I'd like:



Slightly off-topic: I'd also like to know the meaning of the R128_TRACK_GAIN field and how it relates to a dB gain value.
Title: What features would you like to see in opus-tools?
Post by: CoRoNe on 2013-01-22 23:31:53
Perhaps totally off-topic, but could you lend the Matroska-Opus devs a hand?! Being able to put an Opus-stream into a Matroska container is really what I'm looking forward to.
Title: What features would you like to see in opus-tools?
Post by: Seren on 2013-01-23 11:04:39
Can't really think of anything atm except maybe a quality based switch for lazy people, it's not hard to implement and I can't see the harm in doing so.

Perhaps totally off-topic, but could you lend the Matroska-Opus devs a hand?! Being able to put an Opus-stream into a Matroska container is really what I'm looking forward to.

Quote
2012-12-31  Moritz Bunkus  <moritz@bunkus.org>

        * mkvmerge: new feature: Added experimental support for the Opus
        audio codec. Parts of an implementation of #779.
Title: What features would you like to see in opus-tools?
Post by: mamboman on 2013-01-23 11:56:44
Yes, converting flac to opus will be a very common use case so support for that would be terrific.

Important in relation to this I believe is to be able to preserve all tag info.

One problem with oggenc was that it did not preserve embedded album art (see link below).

http://superuser.com/questions/169151/embe...d-line-in-linux (http://superuser.com/questions/169151/embed-album-art-in-ogg-through-command-line-in-linux)

However, some folks may not want to have album art embedded in their opus files for space saving reasons or whatever, so i suggest there might be a command line switch to prevent album art embedded in flac files from being embedded in the opus files if so desired.
Title: What features would you like to see in opus-tools?
Post by: nu774 on 2013-01-23 12:12:57
Slightly off-topic: I'd also like to know the meaning of the R128_TRACK_GAIN field and how it relates to a dB gain value.

If I remember correctly, it was something like the following:
Code: [Select]
replaygain_album_gain = OpusHead.output_gain / 256.0 + 5.0
replaygain_track_gain = R128_TRACK_GAIN / 256.0 + replaygain_album_gain
Title: What features would you like to see in opus-tools?
Post by: DonP on 2013-01-23 12:14:23
Can't really think of anything atm except maybe a quality based switch for lazy people, it's not hard to implement and I can't see the harm in doing so.


Easiest way is just to allow "quality" as the equivalent to the existing "bitrate," so you could then specify, for example, quality=64.  If that doesn't solve your problem, it's because you don't accept that vbr is quality based.

Title: What features would you like to see in opus-tools?
Post by: nu774 on 2013-01-23 14:15:44
If I remember correctly, it was something like the following:
Code: [Select]
replaygain_album_gain = OpusHead.output_gain / 256.0 + 5.0
replaygain_track_gain = R128_TRACK_GAIN / 256.0 + replaygain_album_gain

Maybe I should explain more...
OpusHead.output_gain and R128_TRACK_GAIN are 16bit signed integer, but actually are Q7.8 fixed point decimal values. So you have to divide by 256.0 to obtain actual value.
As for R128_TRACK_GAIN, opusinfo prints raw (integer) value.
On the other hand, "Playback gain" shown by opusinfo is already divided, and is equals to OpusHead.output_gain / 256.0.
5.0 offset in the equation above is due to difference of normalize level between replaygain and R128.
Title: What features would you like to see in opus-tools?
Post by: lvqcl on 2013-01-23 14:40:06
Currently opusenc requires the output filename and doesn't have short options. I'd like to type

Code: [Select]
opusenc -b 96 filename.wav

instead of current:

Code: [Select]
opusenc --bitrate 96 filename.wav filename.opus
Title: What features would you like to see in opus-tools?
Post by: .alexander. on 2013-01-23 18:06:47
I'm looking for suggested features to get into opus-tools prior to the libopus 1.1 release.


Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps). Also I would love to have complexities 11-20 as everything below complexity 8 seem to cause shorter call duration compared to ISAC.
Title: What features would you like to see in opus-tools?
Post by: gottkaiser on 2013-01-23 18:38:38
...converting flac to opus ... would be terrific...
...preserve all tag info...
...preserve embedded album art...

second that
Title: What features would you like to see in opus-tools?
Post by: Banned on 2013-01-23 18:45:45
Currently opusenc requires the output filename and doesn't have short options. I'd like to type

Code: [Select]
opusenc -b 96 filename.wav

instead of current:

Code: [Select]
opusenc --bitrate 96 filename.wav filename.opus

+1. In general, Opus and Vorbis encoders having the same interface as much as is reasonable would be nice.
Can't really think of anything atm except maybe a quality based switch for lazy people, it's not hard to implement and I can't see the harm in doing so.


Easiest way is just to allow "quality" as the equivalent to the existing "bitrate," so you could then specify, for example, quality=64.  If that doesn't solve your problem, it's because you don't accept that vbr is quality based.
Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.
Title: What features would you like to see in opus-tools?
Post by: DonP on 2013-01-23 19:39:37

Easiest way is just to allow "quality" as the equivalent to the existing "bitrate," so you could then specify, for example, quality=64.  If that doesn't solve your problem, it's because you don't accept that vbr is quality based.
Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.


I don't think any of the encoders using ie q0-5 (vorbis) or V5-0 (lame) have that perfectly nailed either.  Look at the public listening tests and you will generally see that both the transparency of a given encoder and the relative ranking of encoders varies with the test sample. 
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-01-23 20:31:38
Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.
That can only be true with a "perfect" lossy encoder— it's not true for any existing one.  If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.

In any case, VBR mode is a quality mode. The quality scale is bitrate indexed against some arbitrary large diverse collection, so the quality value scale has ~some~ meaning instead of being completely meaningless as it is for Vorbis.
Title: What features would you like to see in opus-tools?
Post by: Dynamic on 2013-01-23 22:20:40
I think there was a time when VBR quality scales tended to be tuned for transparency only at one specific, 'standard' setting and often didn't have much of a variable quality scale above and below that, although they often offered extreme or insane settings too.

I guess historically, that was LAME --alt-preset standard (now -V2) and Musepack standard (aka q 5) where the respective psymodels were extensively tuned.

There's maybe some idea that Vorbis -q5 is sort of equivalent and that neroaacenc at 0.5 might be in the same ballpark, but both formats have toolkits that greatly help in obscuring artifacts without the sudden degradation in quality at lower bitrates. Even LAME now does very nicely at -V4 (formerly medium) and -V5 despite having fewer tools to hide artifacts of encode with great-efficiency than more modern codecs.

In many ways the typical generalised graphs that show a sort of rising quality reaching some sort of 'knee' before rolling over to a fairly flat region of diminishing gains with bitrate are a reasonable picture, and I suspect that the special low-bitrate tricks like Contrained Energy per critical band (very well implemented in Opus/CELT, fairly well in Vorbis) and PNS and SBR have reduced the rate of deterioration 'below the knee' in the most modern music codecs so that artifacts and stereo changes can be discerned but are rarely annoying (though for AAC+v2, I find 32kbps stereo high end pretty annoying and much prefer Opus at 32)

SPEECH/MUSIC mixes
I would say that a difference arises in Opus (and to some extent other codecs) depending on whether one is encoding speech or music. Speech seems to be remarkably good at much lower quality settings and much lower audio bandwidths than music, which offer more codec-killing sounds, more stereo separation and more high frequency content than speech. I'd guess that certain VBR codecs would dip their bitrate during speech faster than opus does, albeit from a higher starting point - often LAME -V5 would dip a lot just thanks to the monophonic content of most speech, as it does with a lot of vintage material that's mono or hard-panned stereo. I'd guess that Opus's efficiency in low-rate stereo encoding wouldn't allow so much of a dip because it's better in the first place.

In Opus I can imagine that if I were after highly acceptable speech coupled with very good sounding stereo music for, say, a podcast, my optimum might be around 24 to 32 kbps for the speech segments and around 64 kbps for the music, or 80 to 96 for really rather good music reproduction for music enthusiasts. Then again, for normal podcasts with only incidental music, 32kbps produces nice sounding music (quite like cassette tape without the hiss) and great speech, and from about 48 kbps things really start to sound fairly good with music - superficially very nice, having full bandwidth and stereo and no egregious artifacts like warbling or splashy applause that codecs like RealAudio used to produce.

I could see some advantage in a future switch for podcasts and audiobooks (or a mode built into a podcast/radio-show creation program) that automatically switches between quite a high bitrate target for stingers and music sections (32, 48, 64, 80, 96, 128 say) and a much lower bitrate target for speech sections (16, 20, 24, 32, say). Essentially, that mode is telling Opus that quality preservation isn't the main aim so long as speech is fairly good and music pretty nice, and that bitrate economy is more important. The easiest solution (if we wish to optimize more than using 32 kbps) is to put it in a podcast editor, of course, which can be told which clips are music or can have these clips ready-encoded to Opus at the optimum bitrate target (e.g. theme music and stingers) and can simply take advantage of the seamless switching of any Opus decoder.

Many talk podcasts I listen to now, would be awesome at a steady 32kbps target like now. Some could save costly hosting bandwidth by using 16/32 mix (and being talk would barely average over 16) or plain 16 or 24 target with theme music carefully selected so as not to sound awful (try transcoding the Windows 7 sample tune "C:\Users\Public\Music\Sample Music\Sleep Away.mp3" to 32 kbps or less to hear awful, with the brused snares especially in SILK mode, whereas "Ninja Tuna.mp3" and "Maid With The Flaxen Hair.mp3" in the same folder transcode to sound OK at 32kbps - all with libopus 1.0.2, that is).

Title: What features would you like to see in opus-tools?
Post by: saratoga on 2013-01-23 22:32:49
I'm looking for suggested features to get into opus-tools prior to the libopus 1.1 release.


Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps).


Thats probably not realistic.  Or at least an enormous amount of work. 
Title: What features would you like to see in opus-tools?
Post by: .alexander. on 2013-01-23 23:04:36
Thats probably not realistic. Or at least an enormous amount of work.


That may be, but fixed point research required for this should be much easier than designing a codec.
Title: What features would you like to see in opus-tools?
Post by: jmvalin on 2013-01-24 01:02:53
Do you accept feature request for codec itself? I would love to have fixed point version providing the same encoding quality as floating point (now fixed point is certainly worse - tested on SAQM recordings at 6-12 kbps). Also I would love to have complexities 11-20 as everything below complexity 8 seem to cause shorter call duration compared to ISAC.


What's your concern with the fixed-point code. As of 1.0.2, we've never observed much of a quality difference between float and fixed-point. In 1.1-alpha, there's a new feature that's float-only, but the fixed-point should still be at least as good (if not better) than 1.0.2.
Title: What features would you like to see in opus-tools?
Post by: azaqiel on 2013-01-24 03:41:43
I would like an opus gain tool that ONLY TAGS the R128 value(s).  tagging instead of altering the actual audio is what I'm referring to.  I would also like a command-line tagging tool.

as far as going from lossless to Opus, I use WavPack, but I'm not going to request WavPack input because I use foobar2000 anyway.
Title: What features would you like to see in opus-tools?
Post by: LithosZA on 2013-01-26 11:40:19
A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?

If these are possible otherwise please ignore:
- Intensity Stereo threshold setting; tweaking it for low bitrates.
- Force CELT/SILK/Hybrid setting.
Title: What features would you like to see in opus-tools?
Post by: IgorC on 2013-01-26 12:09:23
Intensity stereo (IS) setting as all other phsycoacoustic settigns shouldn't be visible for user imo. LAME was a good example of that. Remember  q0, k settings mess? Those are dangerous to play with.

P.S. You still can try it for testing purpose.
Title: What features would you like to see in opus-tools?
Post by: bat_guano on 2013-01-26 18:02:35
I'm looking for suggested features to get into opus-tools prior to the libopus 1.1 release...

Hi
In my other thread here ---> other thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=99060)
I have problems with dumped opus files.
There's something wrong with the timestamps (or whatever).

Could a tool be included to re-mux opus files and clean up these errors?


Perhaps this might utilize opusinfo, which seems to give accurate information.


Code: [Select]
timeout 30 \
mplayer -nocache -dumpstream -dumpfile SmoothJazz3.opus \
"http://radioserver1.delfa.net/64.opus"


See below, opusinfo shows correct duration, bitrates etc but mediainfo is confused.

Quote
@ubuntu:~$ opusinfo SmoothJazz3.opus
Processing file "SmoothJazz3.opus"...

New logical stream (#1, serial: 1aca3133): type opus
Encoded with libopus 1.0.2
User comments section follows...
   ENCODER=scripts
   TITLE=Eyes Down
   TRACKNUMBER=7
   TRACKTOTAL=9
   GENRE=Smooth Jazz
   DATE=2010
   COMMENT=From RAW PCM to opus
   ARTIST=Shilts
   ALBUM=Going Underground
WARNING: sequence number gap in stream 1. Got page 36 when expecting page 2. Indicates missing data. (normal for live streams)
WARNING: discontinuity in stream (1)
WARNING: EOS not set on stream 1 (normal for live streams)
Opus stream 1:
   Pre-skip: 356
   Playback gain: 0 dB
   Channels: 2
   Original sample rate: 44100Hz
   Packet duration:  20.0ms (max),  20.0ms (avg),  20.0ms (min)
   Page duration:  1000.0ms (max), 1000.0ms (avg), 1000.0ms (min)
   Total data length: 269093 bytes (overhead: 1.05%)
   Playback length: 0m:32.992s
   Average bitrate: 65.25 kb/s, w/o overhead: 64.56 kb/s



Quote
@ubuntu:~$ mediainfo SmoothJazz3.opus
General
Complete name                            : SmoothJazz3.opus
Format                                  : OGG
File size                                : 263 KiB
Duration                                : 1mn 7s
Overall bit rate                        : 32.1 Kbps
Album                                    : Going Underground
Track name                              : Eyes Down
Track name/Position                      : 7
Track name/Total                        : 9
Performer                                : Shilts
Genre                                    : Smooth Jazz
Recorded date                            : 2010
Writing application                      : scripts
Comment                                  : From RAW PCM to opus

Audio
ID                                      : 449458483 (0x1ACA3133)
Format                                  : Opus
Duration                                : 1mn 7s
Channel(s)                              : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 44.1 KHz
Compression mode                        : Lossy
Writing library                          : libopus 1.0.2


Quote
Title: What features would you like to see in opus-tools?
Post by: nu774 on 2013-01-27 16:42:01
Bitrate might be surely enough when one is working only with constant (say, redbook) format.
However, if bitrate is the only way for quality contorl and when one is working with varying formats, one will have to take several parameters (such as # of channels, channel coupling, input sampling rate) into account, and manually scale bitrate by hand to obtain desired quality.
Therefore, I think quality scale would be useful.
Title: What features would you like to see in opus-tools?
Post by: Dynamic on 2013-01-28 02:30:49
I think QAAC's TVBR settings are roughly half the stereo bitrate in kbps, essentially amounting to bitrate-per-channel.

If people get accustomed to Opus quality in stereo mode (but maybe mono for speech) maybe a stereo-equivalent bitrate switch would suffice for surround (amounting to constant quality regardless of channel count).
Title: What features would you like to see in opus-tools?
Post by: Banned on 2013-01-28 17:26:24
Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.
That can only be true with a "perfect" lossy encoder— it's not true for any existing one.  If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.
Where do I report these?
In any case, VBR mode is a quality mode. The quality scale is bitrate indexed against some arbitrary large diverse collection, so the quality value scale has ~some~ meaning instead of being completely meaningless as it is for Vorbis.
Is that related to first part of your post? I never objected to the idea of using average bitrate on some collection as a quality measure.
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-02-04 18:58:59
If people get accustomed to Opus quality in stereo mode (but maybe mono for speech) maybe a stereo-equivalent bitrate switch would suffice for surround (amounting to constant quality regardless of channel count).
We've at least talked about making it 'full-band stereo quality equivalent'.  The downside would be when you ask for 24kbit/sec mono for speech (which sounds pretty good) and end up getting 8kbit/sec which does not sound so great.

Well, it doesn't look to me that it's quality based. For me, "quality based" would mean that the minimum quality setting giving a transparent encode is more or less the same for all files. That doesn't seem to be the case with Opus.
That can only be true with a "perfect" lossy encoder— it's not true for any existing one.  If you're aware of bit discrepancies in libopus 1.1a they'd be interesting to know about.
Where do I report these?
Make a post in this subforum, "Samples which aren't transparent at 160kbps with 1.1a" or something like that.
Title: What features would you like to see in opus-tools?
Post by: moosehunter on 2013-02-10 04:43:36
There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.

Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.

And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-02-15 19:02:20
There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.


The codec doesn't really expose a way to "force SILK"  ... that whole thinking of "force silk or celt" is usually the wrong way to think about the codec.... What about hybrid? Opus is not two distinct codecs with a big switch between them.  Unfortunately, I don't have a clue of what goldwave is actually doing. — It would be nice to know.

Quote
Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.
The detection is not that accurate, so that might produce pretty irritating results... sounds worth trying though.

Quote
And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.


Use the --save-range option to opusdec.

Title: What features would you like to see in opus-tools?
Post by: jensend on 2013-02-15 19:22:21
Wrote much of this almost a week ago; realized I still had the unfinished reply sitting around, and though it's late it still seemed worth saying.
There are a few things that I'd like to see. In opusenc, an option to force SILK or CELT. Goldwave already does this, and when I encode a 24kbps with SILK in Goldwave, it sounds much better than the opusenc file. This changes when you get down to 16kbps.
I find it somewhat odd that you're getting better results by forcing SILK-only at those rates; it'd normally be using hybrid. Once you get down to 16kbps it'll usually be doing SILK-only even if you don't force it. Have you looked at the output bandwidth and verified that it's only wideband? ABC/HR type blind test data confirming your preference for forced SILK would be interesting.

The mode decisions in the present encoder are fairly reasonable and will continue to be refined; thus I don't think forcing a mode is usually going to be beneficial. Also, the developers are understandably reluctant to give people options that either give them a false sense of control or allow them to shoot themselves in the foot. Nevertheless, I do want to echo the request for ways to constrain the encoder's mode and bandwidth decisions with opusenc, because I do think there are legitimate use cases. For instance, for playback on very constrained devices (e.g. many Rockbox targets), it'd be nice to be able to restrict the encoder for performance and/or battery life reasons.

With the 1.0.x encoder you could just choose a bitrate which would reliably give you the mode and bandwidth you wanted, but the adaptability of the master branch eliminates that predictability.

Another use case: I have speech recordings where the master branch encoder encodes them as fullband or keeps switching between FB and SWB but the content above 12kHz seems unhelpful. Some consonants, applause, and some noises (like dropping stuff on the podium) have appreciable HF content, but I think they're adequately represented by their energy below 12kHz. There are some noises in a few recordings- like background silverware- that are audibly affected by a 12kHz cutoff, but that's actually an improvement, since the noise is made slightly less distracting. Outside of that I don't know that I can even ABX 12kHz lowpassed versions of this material. I'd rather have those bits go to lower frequencies, and though the FB<->SWB transitions often aren't audible I think there's more danger of such transitions being audible than there is of the >12kHz content being missed. I think this situation is pretty common for speech, and while I could of course pass the encoder versions that I've lowpassed or resampled myself, it would be convenient to be able to just tell the encoder to not do FB.

Quote
Going along with the voice/music detection in the 1.1-alpha, I don't know if it would be feasible, but it would be nice to dynamically scale the bitrate between detected music and voice portions of a clip with user specified bitrates for each, where the user might choose to set a bitrate of, say, 24kbps for voice, and a higher bitrate of 128 kbps for music.
This seems to come up frequently- one discussion has been moved from the old huge "ready for testing thread" to its own thread (http://www.hydrogenaudio.org/forums/?showtopic=99494).

Quote
And in opusinfo, a printout or graph of the bitrate vs time in the file, or maybe just a printout of the bitrate each frame, or the average bitrate at a user specified interval, so you could get a listing of the average bitrate every second, or whatever the user might specify. This might be useful for analyzing how your audio is being encoded.
opusenc's --save-range already dumps each frame's framelength and size, mode and bandwidth info, etc. Not the most handy format for visualization etc, and the only documentation that tells you what's what is reading the code (http://git.xiph.org/?p=opus-tools.git;a=blob;f=src/diag_range.c), but the info is there for the parsing. Obviously that doesn't help if you're trying to analyze files you encoded with some other program or files you received from a third party.
Title: What features would you like to see in opus-tools?
Post by: moosehunter on 2013-02-17 23:31:21
Use the --save-range option to opusdec.

Cool, didn't realize you could do that, thanks. Is there a place that tells you what each part of the printout means? I had to dig into the source to figure it out.

Oh, and I don't know if anyone's mentioned it yet, it seems pretty obvious anyway, but it goes in with the FLAC support. Transferring the tag and image to the encoded files like the reference FLAC encoder does would be nice.
Title: What features would you like to see in opus-tools?
Post by: moosehunter on 2013-02-18 00:49:07
(Can you not edit your posts?)
I find it somewhat odd that you're getting better results by forcing SILK-only at those rates; it'd normally be using hybrid. Once you get down to 16kbps it'll usually be doing SILK-only even if you don't force it. Have you looked at the output bandwidth and verified that it's only wideband? ABC/HR type blind test data confirming your preference for forced SILK would be interesting.

Ahh, that was the difference. Goldwave was encoding it as super-wideband. The difference was usually night and day, depending on the voice of the person. One of the samples with the least difference between the two was the speech sample on the opus example page. I attached the two different encodes.

Given that discovery, I'd agree with the option to let the user choose the bandwidth of the output file.

opusenc's --save-range already dumps each frame's framelength and size, mode and bandwidth info, etc. Not the most handy format for visualization etc, and the only documentation that tells you what's what is reading the code (http://git.xiph.org/?p=opus-tools.git;a=blob;f=src/diag_range.c), but the info is there for the parsing. Obviously that doesn't help if you're trying to analyze files you encoded with some other program or files you received from a third party.

Well, just feed the data into Excel, and it displays it just fine. And nevermind about my question about documentation, I didn't read this before I posted that.
Title: What features would you like to see in opus-tools?
Post by: LithosZA on 2013-02-18 05:45:10
Quote
A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?


Quote
Given that discovery, I'd agree with the option to let the user choose the bandwidth of the output file.

+1
Title: What features would you like to see in opus-tools?
Post by: jensend on 2013-02-18 16:00:42
You can edit your posts- but only for one hour after you post (http://www.hydrogenaudio.org/forums/index.php?showtopic=72003), since following a discussion gets pretty strange when you can't see what people were replying to. I can appreciate that this is sometimes inconvenient. For instance, my post above looks a little silly, as though I hadn't read the last part of NullC's reply, since I clearly didn't know --save-range was available in opusdec when I wrote most of the reply a week ago. (I'd frequently used it in opusenc but hadn't ever had reason to think about it on the decoding side.) I didn't notice the anachronism until just over an hour after I posted it, and it wasn't worth another reply by itself.

Ahh, that was the difference. Goldwave was encoding it as super-wideband. The difference was usually night and day, depending on the voice of the person. One of the samples with the least difference between the two was the speech sample on the opus example page. I attached the two different encodes.
Interesting. I don't think Goldwave was forcing a higher bandwidth; it was just using libopus 1.0.1, which by default will simply and predictably use hybrid SWB at those bitrates. The pre-1.1 encoder adapts more to its input, and my experience has usually been that it bumps the bandwidth up at considerably lower bitrates than 1.0.x did. With this file, the opposite happened- it quickly switched from SWB to just WB and stayed there.

This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.
Title: What features would you like to see in opus-tools?
Post by: moosehunter on 2013-02-19 00:56:28
This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.

That file was just an example. Pretty much all other files I tested did the same thing.
Title: What features would you like to see in opus-tools?
Post by: jmvalin on 2013-02-19 06:11:01
Interesting. I don't think Goldwave was forcing a higher bandwidth; it was just using libopus 1.0.1, which by default will simply and predictably use hybrid SWB at those bitrates. The pre-1.1 encoder adapts more to its input, and my experience has usually been that it bumps the bandwidth up at considerably lower bitrates than 1.0.x did. With this file, the opposite happened- it quickly switched from SWB to just WB and stayed there.

This file is quite quiet- peaking at -14 dB, ReplayGain of ~+10 - and the encoder must be making its bandwidth detection decisions on an absolute rather than relative basis. If you amplify the file by 12dB, then 1.1-alpha quickly switches to FB and stays there for the length of the file. This seems like undesirable behavior.


I just checked in a fix in master that should address this issue. It was mostly due to a bug where trying to vary the bandwidth too quickly could leave the encoder stuck in wideband mode. As for the bandwidth detection, it's actually using both relative *abd* absolute thresholds. The absolute thresholds are needed because quantization noise adds energy to all bands. At low volume it can sometimes be hard to  tell the difference between quantization noise and actual signal energy.
Title: What features would you like to see in opus-tools?
Post by: Omicron on 2013-02-21 11:28:50
It would be good to make a feature in encoder so user do not need to choose bitrate. Encoder chooses the optimal bitrate at which human couldn't distinguish encoded file from the original.
Title: What features would you like to see in opus-tools?
Post by: azaqiel on 2013-02-21 20:15:06
@Omicron:

impossible.  how would the said encoder know how good the music should be, or how good the listener wants it to be, or even how good of a listener the listener is at listening?

off topic: if you think the answer is "as good as it can be", try lossless.
Title: What features would you like to see in opus-tools?
Post by: db1989 on 2013-02-21 20:22:26
It would be good to make a feature in encoder so user do not need to choose bitrate. Encoder chooses the optimal bitrate at which human couldn't distinguish encoded file from the original.
Oh, here we go again. You have two things to realise:

(1) Allowing a choice of quality and a bitrate that varies depending upon the complexity of the input stream are basic features of modern codecs in VBR modes.

(2) Encoders are not psychic, perceptual modelling is not perfect, listeners are not identical, and these statements are all negative by definition.

It is impossible for an encoder to conclude that x file at y quality will be transparent to “human”, assuming you mean everyone. And it’s impossible for them to guarantee the same thing for any single human.

But encoders already provide sliding scales, based upon various psychoacoustic metrics and without worrying much about bitrate, that allow the individual user to choose from various levels of quality and find one that is generally transparent to him/her.

It would be much easier just to accept this, do a few tests, pick an encoder and quality level, and not worry about it unless anything ever sounds audibly different to you personally.
Title: What features would you like to see in opus-tools?
Post by: kennedyb4 on 2013-02-21 22:41:38
Tags that would work in Rockbox would be great.
Title: What features would you like to see in opus-tools?
Post by: Omicron on 2013-02-22 21:01:20
Quote
how would the said encoder know how good the music should be

I think it's possible. May be it's difficult to do, but it's possible. Needs one more algorithm for such a work and some sound experts with good/perfect hearing to find that optimal quality when nobody could distinguish the differences.

Quote
if you think the answer is "as good as it can be", try lossless.

You are Captain Obvious, aren't you?)

Quote
It is impossible for an encoder to conclude that x file at y quality will be transparent to “human”, assuming you mean everyone. And it’s impossible for them to guarantee the same thing for any single human.

OK, for any sound expert while developing algorithm. So no one in the world could carp for none perfect quality.

Quote
and find one that is generally transparent to him/her.

For this I need to find out the optimal bitrate just for one track. And I need to do this over and over again. So it's easier to use always 510kbps or use lossless, and it's not quite good for disk space.

For one of the sound it's impossible to distinguish differences at 128kbps, for other at 96kbs. So encoder chooses the optimal quality for each sound more variable not only over the chosen bitrate. 'cos, for example, when I encode mp3(v0) to opus(512) (I know that it's not good to do this, it's just for an example), opus is 7.48mb, while mp3 was 4.43. Do you know what I mean?

If it is a bad idea or very difficult to do, just... never mind.
Title: What features would you like to see in opus-tools?
Post by: db1989 on 2013-02-22 21:30:30
Is there something contagious going around Hydrogenaudio recently that’s making people misunderstand how VBR encoders work and ignore what people actually write in explanatory replies? I really lack the energy to repeat myself in slightly different words in the hope that something will change, but hey, I’m going to try anyway.

• Encoders are not perfect and cannot always achieve the same level of theoretical quality for all tracks.
• A given level of quality being transparent on one input signal to one listener is not guaranteed to be transparent on across all, or even any, other material.
An encoder cannot possibly know which level of theoretical quality will be transparent to you, as a single individual.

Thus, as much as you evidently want to find a reliably transparent level of quality – but equally, and emphatically, don’t want to do the leg-work that is a necessary corollary – you can either put in the effort and possibly get it, or not put in the effort and don’t. Miracles like a psychic encoder that can guarantee transparency on all signals at minimal size just for you are a nice thought, but so are lots of other things that aren’t and cannot ever be real. That’s a limitation that extends far beyond audio encoding.
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-02-22 22:44:13
Is there something contagious going around Hydrogenaudio recently that’s making people misunderstand how VBR encoders work and ignore what people actually write in explanatory replies?
Yes. There is. Encoders that have "quality" knobs are apparently misunderstood as actually achieving the ideal they aspire to. This wasn't obvious to me before because it's not the sort of misconception that causes comments.

I will probably add a --quality knob that is just an alias for bitrate which will likely silence the complaints at some point... but I'm not in a rush to do it.

A maximum bandwidth setting. In libopus the bandwidth seems to lower automatically when I lower the bitrate, but it seems to be different with opusenc?
If these are possible otherwise please ignore:
- Intensity Stereo threshold setting; tweaking it for low bitrates.
- Force CELT/SILK/Hybrid setting.
Some amount of forcing is possible now via the undocumented set-ctl arguments.  Though there is no analog of a settable intensity threshold in our encoder.

Bandwidth and bitrate behavior should be the same w/ libous/opusenc. The only major non-default thing opusenc does is that its VBR by default.

Generally, I am not eager provide detailed internal DSP influencing knobs— at least not as documented user-visible features. The reason for this is simple: If it were easy to set in an improved way the system would do it for you already. If I can't manage to improve the default behavior— knowing how the codec works, having experience and patience with blind testing, and having access to test subjects (you guys)— then it is really unlikely that users of the software— especially ones who haven't shown up in IRC and found out about the undocumented switches— will actually change the settings in a way that will make an improvement... maybe they'll get something that sounds a bit better on the first ten seconds of one sample, then they'll post it up on some less scientifically minded audio forums and people are then cargo-culting it.  Meanwhile, exposing knobs takes time and creates more chances for bugs. It's just not generally a good tradeoff in my experience.



Title: What features would you like to see in opus-tools?
Post by: jmvalin on 2013-02-23 01:29:28
I think it's possible. May be it's difficult to do, but it's possible. Needs one more algorithm for such a work and some sound experts with good/perfect hearing to find that optimal quality when nobody could distinguish the differences.


Great to hear you know how to do this! I'm eagerly waiting for your patch that implements this and proves us all wrong. We can do a special release just for that for that feature. When are you planning on sending us the code? Thanks in advance.
Title: What features would you like to see in opus-tools?
Post by: jensend on 2013-02-23 19:48:23
I will probably add a --quality knob that is just an alias for bitrate which will likely silence the complaints at some point... but I'm not in a rush to do it.
As I tried to say in the other "bitrate vs quality" thread before it went off the rails, adding a --quality knob isn't just cosmetic because it allows you to do what you were talking about with "fullband stereo quality equivalent" without causing confusion or dismay. As you said, if somebody puts --bitrate x for their 22kHz mono speech recording and gets a bitrate of x/3 they will be surprised. However, if they put --quality x for their 22kHz mono speech and get a bitrate 1/3 what they get when they encode 44kHz stereo music with the same quality level, that is perfectly normal expected behavior. Likewise for getting 3x the bitrate for 5.1 surround.

It may sound trivial but it really does improve the user experience when you name things in a way that helps people have the right expectations.
Quote
Some amount of forcing is possible now via the undocumented set-ctl arguments. . . Generally, I am not eager provide detailed internal DSP influencing knobs— at least not as documented user-visible features. The reason for this is simple: If it were easy to set in an improved way the system would do it for you already. If I can't manage to improve the default behavior— knowing how the codec works, having experience and patience with blind testing, and having access to test subjects (you guys)— then it is really unlikely that users of the software— especially ones who haven't shown up in IRC and found out about the undocumented switches— will actually change the settings in a way that will make an improvement... maybe they'll get something that sounds a bit better on the first ten seconds of one sample, then they'll post it up on some less scientifically minded audio forums and people are then cargo-culting it.  Meanwhile, exposing knobs takes time and creates more chances for bugs. It's just not generally a good tradeoff in my experience.
*sigh*

For those not in the know, the CTLs are in include/opus_defines.h (http://git.xiph.org/?p=opus.git;a=blob;f=include/opus_defines.h;h=cdde061a567323fd5ebb75a6caf1e279a88f2409;hb=HEAD) in the opus source code. The main CTLs of interest are OPUS_SET_MAX_BANDWIDTH_REQUEST, OPUS_SET_APPLICATION_REQUEST, and OPUS_SET_SIGNAL_REQUEST.

Trying to make Opus use a higher bandwidth than normal, for which you would use OPUS_SET_BANDWIDTH_REQUEST, is dangerous to your audio quality. Only cases I can think of where it might help are encoder bugs like the one jmv just fixed above and some very artificial stuff like the noisy high-frequency test files softrunner talked about in the 1.1a thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=99495&view=findpost&p=824191). When Opus drops to a lower bandwidth it generally has very good reasons for doing so.

The CTLs may change in the future. In fact, maybe NullC will go change them now to try to prevent people who haven't been through the IRC initiation ceremony and secret handshake from having access to the sacred mysteries through my link, and maybe he'll try to chain me to a rock and have eagles pick at my liver. Caveat emptor atque venditor.

NullC, my reaction to what you've said above:
Title: What features would you like to see in opus-tools?
Post by: darkbyte on 2013-03-13 11:56:25
I think a per channel bitrate setting would be useful. For eg. i'm encoding my music collection recently into 80kbps Opus and i have some mono chiptune albums and they are getting as high bitrate as 100kbps. If i manually encode them using --bitrate 40 kbps i still get very good quality but just a bitrate around 50-60kbps. So a --bitrate-per-channel 40 would be very useful. This will be 40kbps for mono, 80kbps for Stereo. Or maybe an option to provide a bitrate list for different channel configurations. Someone might want to give a mono recording a bit higher bitrate to be on the safe side.
Title: What features would you like to see in opus-tools?
Post by: jmvalin on 2013-03-13 14:30:47
I think a per channel bitrate setting would be useful. For eg. i'm encoding my music collection recently into 80kbps Opus and i have some mono chiptune albums and they are getting as high bitrate as 100kbps. If i manually encode them using --bitrate 40 kbps i still get very good quality but just a bitrate around 50-60kbps. So a --bitrate-per-channel 40 would be very useful. This will be 40kbps for mono, 80kbps for Stereo. Or maybe an option to provide a bitrate list for different channel configurations. Someone might want to give a mono recording a bit higher bitrate to be on the safe side.


Actually, the 1.1-alpha encoder will automatically reduce the bit-rate when the input is mono (well, when the file has two identical channels).
Title: What features would you like to see in opus-tools?
Post by: darkbyte on 2013-03-13 16:19:35
Actually, the 1.1-alpha encoder will automatically reduce the bit-rate when the input is mono (well, when the file has two identical channels).


Strange, i'm using the 1.1-alpha-39-g10a35a5-babyeater build but i'm getting the described 100kbps bitrate on some chiptune samples instead of a lower one. Maybe the source is just sounds Mono to me but it has some differences because of dithering or such.

Btw, i forgot that with --bitrate 40 i'm using the --downmix-mono switch on a stereo source where both channels sound equal to me. Otherwise i get the described 100kbps bitrate. So either the mono detection of Opus doesn't work or my source files are just sound mono.
I think i'll upload a sample.

Mod: here's one 30sec sample (http://www.2shared.com/file/wn-xIqhi/Jeroen_Tel_-_Supremacy.html)
This seems like pure mono sample to me. If you encode it with --bitrate 80 it ends up as 71kbps. If i encode it with --bitrate 40 --downmix-mono it will be a 43kbps Opus and it sounds the same to me.
Looks like the beginning of this track is boosting the bitrate a lot. This track ends up at 100kbps but only if i encode it in it's whole length. This 30sec sample encodes into a close to 80kbps size.  I think i can't upload the whole track here, it's from the commercial CD "C64 Orchestra - Run 10".

It would be interesting to see if the SID directly converted and upmixed into stereo WAV and then encoded with Opus will end up with the same high bitrate.

Mod2: okay i think i've screwed up something. Now i can't reproduce the high bitrate even on the whole length of the song. Maybe i was encoding yesterday with the non babyeater build.

I think you should ignore this post for now.
Title: What features would you like to see in opus-tools?
Post by: jmvalin on 2013-03-13 20:10:30
Strange, i'm using the 1.1-alpha-39-g10a35a5-babyeater build but i'm getting the described 100kbps bitrate on some chiptune samples instead of a lower one. Maybe the source is just sounds Mono to me but it has some differences because of dithering or such.


Please stop testing the babyeater build for now. We've discovered several major issues with it. These need to be fixed (non-trivial) before it's useful to test again.
Title: What features would you like to see in opus-tools?
Post by: polemon on 2013-06-24 16:11:44
All features I'd like to see in opus-tools, have already been requested, I'd just like to add my +1 to them:

* decoding of FLAC files (and perhaps Ogg/PCM)
* short options (opusenc -b 64 input.flac)
* preserving tags info from Ogg containers (Ogg/FLAC, Ogg/PCM)
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-06-27 11:25:09
All features I'd like to see in opus-tools, have already been requested, I'd just like to add my +1 to them:
* decoding of FLAC files (and perhaps Ogg/PCM)
* short options (opusenc -b 64 input.flac)
* preserving tags info from Ogg containers (Ogg/FLAC, Ogg/PCM)
The first and last are already implemented (well, FLAC. Ogg/PCM is ~= non-existent). When I looked at short options before I thought I found contradictory behavior in the programs I preferred to immitate and punted on deciding by not having them, meh. Okay.
Title: What features would you like to see in opus-tools?
Post by: polemon on 2013-06-28 05:55:48
well, FLAC. Ogg/PCM is ~= non-existent [...]


Which is a shame, actually. I really do have a problem because of that. WAV has a maximum time span of something around five and a half hours for a stereo stream. The recordings I do, are sometimes up to eight hours long. I usually have to resort to quite a long number of parameters on the decoder and encoder when piping one into another. Having OggPCM (for whatever reason, it's "OggPCM"[1], and not ("Ogg/PCM") as something for piping etc. would be awesome.

When it comes to how the tool should behave: It should be easy and self-explanatory to use. I understand most of the Xiph tools don't have a unified set of parameters or behaviors. I recommend you do what makes the most "sense".

  [1]: http://wiki.xiph.org/OggPCM (http://wiki.xiph.org/OggPCM)
Title: What features would you like to see in opus-tools?
Post by: skamp on 2013-07-01 10:10:32
an equivalent to vorbiscomment, with the ability to add, remove, replace tags, from the command line or from a text file


Well, Frédéric Mangano released opustags 1.1 (https://github.com/fmang/opustags) a while ago, which has all of the features that I wanted
Title: What features would you like to see in opus-tools?
Post by: Brazil2 on 2013-07-01 12:42:28
Well, Frédéric Mangano released opustags 1.1 (https://github.com/fmang/opustags) a while ago, which has all of the features that I wanted

Any GCC build for Windows available ?
Title: What features would you like to see in opus-tools?
Post by: NullC on 2013-07-01 16:23:22
well, FLAC. Ogg/PCM is ~= non-existent [...]

Which is a shame, actually. I really do have a problem because of that. WAV has a maximum time span of something around five and a half hours for a stereo stream. The recordings I do, are sometimes up to eight hours long. I usually have to resort to quite a long number of parameters on the decoder and encoder when piping one into another.
FWIW, many (most? virtually all?) wav tools— including opusenc— support reading and writing non-standard wav files which are longer.  One of my standard tests for opusenc is encoding a 25 hour stereo 48k wav file.

Quote
Well, Frédéric Mangano released opustags 1.1 a while ago, which has all of the features that I wanted

Cool. I'll see if he wants to add in-place updating— opusenc now adds padding to the comments so it's usually possible to add comments without rewriting the whole file.