-
Notifications
You must be signed in to change notification settings - Fork 586
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for arbitrarily high framesize? #32
Comments
opusenc opus-tools 0.1.9 (using libopus 1.1.4) only supports up to 60ms framesize |
actually I should have compiled your latest git before opening this issue... |
libopus 1.2-alpha2-4-gcfdaf365 |
whats going on here? |
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. |
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. |
Thank you for your input! |
Ah so that explains what I was noticing. Anyway.
... 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 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: