Skip to main content
Topic: Is the bitrate share to all channels? (Read 1987 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is the bitrate share to all channels?

My opusenc version is: opusenc opus-tools 0.2-3-gf5f571b (using libopus 1.3)

I have two files, both from same movie
6.flac (1365MB) <--5.1, 6ch
2.flac (462MB)   <--stereo, 2ch

And I encoded by these commands
opusenc --bitrate 128 6.flac 6.opus
opusenc --bitrate 128 2.flac 2.opus

Finally I got this result
6.opus (122MB)
2.opus (134MB)

Why two opus are simlar size? is the 128 bitrate that share to all channels? if I use same bitreate to encode 6ch and 2ch, I will get a 6.opus that quality worse then 2.opus?

If I want the 6.opus same quality to "opusenc --bitrate 128 2.flac 2.opus"
What bitrate I should use? is it "opusenc --bitrate 384 6.flac 6.opus"?

Re: Is the bitrate share to all channels?

Reply #1
If I want the 6.opus same quality to "opusenc --bitrate 128 2.flac 2.opus"
What bitrate I should use? is it "opusenc --bitrate 384 6.flac 6.opus"?
Quality isn't always proportional to the bitrate, it's called bitrate in opus but it's actually a quality setting, calibrated to give certain bitrate on some large dataset.
Also there isn't any good measure of quality past the point where there's no audible difference to the original.
However: the more channels, the more is the potential to save bits (in comparison to endoding every channel independently to be listened separately) by exploiting similarities across channels and sounds in one channel masking distortion in another channel. And LFE channel usually has a lot simpler content than other channels.
So it should probably be something in between 128 and 384, but 384 is likely "over the top" territory.

Re: Is the bitrate share to all channels?

Reply #2
opusenc -h
--bitrate n.nnn    Set target bitrate in kbit/sec (6-256/channel)

Re: Is the bitrate share to all channels?

Reply #3
It's hard to compare stereo quality to surround quality, mostly because most people will evaluate stereo quality with headphones (as they should because you can hear more details), but surround is meant to be used with speakers. If you're wondering what bitrate to use, just try a bunch of different ones, see at what point you're happy with the quality, and then maybe add a bit of a "safety margin" just to be sure. Or alternatively, just figure out how many bits you can afford and go with that.

 

Re: Is the bitrate share to all channels?

Reply #4
Quote
Is the bitrate share to all channels?
Yes, it's the bitrate for the whole file.

As you may know, there are 8 bits in a byte so 128 kilobits per second is 16 kilobytes per second and if you know the bitrate and playing time you can (approximately) calculate file size.    Or, you can calculate the (approximate-average) bitrate from the file size and playing time.

...Headers and embedded metadata (especially album artwork) adds to the file size without affecting the audio bitrate.  

Re: Is the bitrate share to all channels?

Reply #5
It's hard to compare stereo quality to surround quality, mostly because most people will evaluate stereo quality with headphones (as they should because you can hear more details), but surround is meant to be used with speakers.
I don't know about that. One can certainly evaluate stereo quality on nice speakers, and one can certainly listen to surround sound on headphones with HRTF processing &c. There's nothing stopping MUSHRA or ABC/HR or other kinds of quality comparisons from settling on one listening setup and using samples of both categories.

And any such comparisons will certainly find that, the way opus-tools works now, if you use the same command line etc to encode a mixed collection - one that includes mono speech, stereo music, and surround music with varying channel configurations - the perceived quality of the results will be drastically different for each category. Bitrates where mono speech can't be ABX'd will inevitably have annoying artifacts on 7.1 surround music.

Opus has tried to stick with the line that 'quality=target bitrate; you don't need another quality setting, you just need to trust our VBR.' And as long as people have collections consisting entirely of stereo music, that can almost seem true (though someone whose music library is primarily glockenspiel recordings might be puzzled about the file sizes). But there's simply no way to do a good job of fulfilling that promise when you face things as different as mono speech and 7.1 surround.

Quote
If you're wondering what bitrate to use, just try a bunch of different ones, see at what point you're happy with the quality, and then maybe add a bit of a "safety margin" just to be sure. Or alternatively, just figure out how many bits you can afford and go with that.
In other words, the recommendation is that every user will have to do a bunch of finicky subjective testing for every different channel configuration, and then make absolutely sure not to encode any of their 7.1 files with the same settings as their 5.1 files or whatever.

It would be a lot nicer if people could figure out a setting that meets their needs for one type of recording and expect the encoder to do an modestly intelligent job of hitting that same quality level for other recordings. This is something that most encoders make some attempt to do.

And lo and behold, nearly eight years ago NullC proposed exactly such a mode (calling it something like 'fullband stereo equivalent bitrate' to avoid the dreaded Q-word). This has come back up from time to time, and each time you've said essentially 'we might get around to it sometime.'

I appreciate that Xiph/Moz folks have been busy with the AV1 push, RTCWEB before that, and that consumers encoding their at-rest files at home has never been what pays the bills. But even a rough pass at some kind of quality mode would be appreciated, and would have handily avoided confusing new users like fejij.

Re: Is the bitrate share to all channels?

Reply #6
I agree that a true quality setting would be more useful than some weirdly defined guesstimated bitrate setting.

Re: Is the bitrate share to all channels?

Reply #7
And lo and behold, nearly eight years ago NullC proposed exactly such a mode (calling it something like 'fullband stereo equivalent bit rate' to avoid the dreaded Q-word).
If the q word is quality, what is dreaded about it? I haven't been keeping up with the trends so I'm likely missing something. Can someone explain?

Anyway I would also love to see a quality setting in Opus. I am fairly certain that I am satisfied with Opus at 96kbps stereo in VBR mode, so I am going to start using that as my ideal quality/compression ratio. However some of my content is mono. I know that using a bit rate of 48 for mono will sound worse than 96 for stereo, and using a bit rate of 96 for mono will sound better. So I guess I'd be aiming for somewhere in the middle.

What I may end up doing is converting my mono files to 96 kbps sterreo and seeing what the VBR does with that. If nothing comes of it, I'll just have to do listening tests to see what an equivalent mono-sounding target is.

From what I understand, the unconstrained VBR in Opus has been tweaked to make the best of its strengths and its weaknesses. Quality just seems a more appropriate means to advertise these kinds of tweaks to a VBR algorithm. Bit rate seems to be just counterintuitive. I know Opus/Celt was originally designed for streaming and low delay use, where bit rate is important. But now I think that with an unconstrained tweaked VBR algorithm, Opus is becoming mature enough to consider a quality scale.

If the VBR is truly unconstrained, then we already have a quality setting that just is controlled by a bit rate value rather than a quality value. I'm getting the idea that a quality scale wouldn't be hard to devise. It would simply map different quality levels to different bit rates, of course taking into account the number of channels. It might seem a cheap way to approximate a quality setting but if the VBR is unconstrained, I think it would work if it's made well.

 
SimplePortal 1.0.0 RC1 © 2008-2019