Support for arbitrarily high framesize?

[Qwertylex]

I'm trying to experiment with extremely low bitrates and would like to set my frame size to 1000 ms or higher, even if that sounds crazy to you.

[Qwertylex]

opusenc opus-tools 0.1.9 (using libopus 1.1.4)

only supports up to 60ms framesize

[Qwertylex]

actually I should have compiled your latest git before opening this issue...

[Qwertylex]

libopus 1.2-alpha2-4-gcfdaf365
Unsupported frame size: 1200 ms. Supported are 2.5, 5, 10, 20, 40, 60, 80, 100, 120.

[Qwertylex]

$ ./opus_demo -e audio 48000 1 16000 -cbr -framesize 120 Anuna\ 48k.wav anuna.opus
libopus 1.2-alpha2-4-gcfdaf365
Encoding 48000 Hz input at 16.000 kb/s in auto bandwidth with 5760-sample frames.
average bitrate: 16.000 kb/s
maximum bitrate: 16.000 kb/s
active bitrate: 16.000 kb/s
bitrate standard deviation: 0.000 kb/s
$ file anuna.opus
anuna.opus: data
$ mpv anuna.opus
Playing: anuna.opus
Failed to recognize file format.

whats going on here?

[rillian]

opus_demo doesn't make .opus files. It uses a custom format just for testing. You need to use opusenc from the opus-tools package to create files other applications can play.

[rillian]

I'm trying to experiment with extremely low bitrates and would like to set my frame size to 1000 ms or higher, even if that sounds crazy to you.

This isn't possible in the opus bitstream. As the encoder reported, 120 ms is the maximum duration of a single frame/packet. At that point there's no meaningful reduction in overhead for encoding longer frames. Meanwhile, longer frames reduce quality by preventing the encoder from switching modes as the character of the audio changes.

The default 20 ms frame size was chosen as the best trade-off between encoding latency and framing overhead. If you're making .opus files and don't care about encoding latency, then that works well. For RTP longer frames are helpful when bitrate is more important than latency, because the framing overhead is so much larger than in .opus.

[Qwertylex]

Thank you for your input!
opusenc does not yet support 120ms frames however...

[Qwertylex]

Meanwhile, longer frames reduce quality by preventing the encoder from switching modes as the character of the audio changes.

Ah so that explains what I was noticing.

Anyway.
https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use.3F

Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.

... So I assumed the inverse was true, that larger framesizes (>20) would be better at a low bitrate...

I re-encoded some flac to 16kbps 2.5, 5, 20, 40, 60ms framesizes
( https://anuna.bandcamp.com/track/s-do-mhaimeo )
2.5 sounded like a robot drowning down a deep well
5 sounded like it had lost all high frequency sounds
20 sounded like what you'd expect for 16kbps opus
40 sounded like 20 but sounded like it was breaking up/ kinda choppy sounding
60 sounded like it was clipping waveforms

assuming that higher framesizes are supposed to sound better, I figured maybe it is just giving me higher frequencies and thus I'm hearing more artifacts, so I was curious as to what 1000ms would sound like.

[jmvalin]

Note that unless you're using RTP and the related header overhead, you're not gaining anything from using frame sizes larger than 20 ms. If your application is encoding low bitrate music to file, then the best frame size to use is 20 ms, not 60 ms, not 120 ms. Using larger frame sizes just concatenates 20 ms frames, but it prevents the encoder from making optimal decisions.