Closed cumtb-edu-loo closed 2 years ago
If you use opusenc to encode a wav file and then opusdec to decode, the duration of the resulting wav file should be the same (for up to 48 kHz sample rate). What sample rate and duration are your original and decoded wav files?
opus_demo only produces complete packets, which are 20 ms by default, so using opus_demo it is expected that the duration will be off by up to 1 packet.
I noticed the same issue after trying opusenc today (see https://github.com/xiph/opus/issues/249), and while there indeed is a small (added) duration difference with PCM inputs, its even worse with flac inputs.
I investigated the flac issue, and it seems to be caused by the latest commit https://github.com/xiph/opus-tools/commit/5d0ac2030244b33bf12512267fe62ffe831bf105
More specifically, it looks like during input file identification, too much data is being consumed, causing some data at the start to be lost. If I revert this change, the output duration is now again the same as with a PCM input (so still not exactly like the original)
while there indeed is a small (added) duration difference with PCM inputs
Actually, after looking at the output with opusinfo
, I'm not so sure anymore about this. It reports a playback length of 44.119s
, while audacity reports a length of 44.134s
(I think audacity uses ffmpeg to decode the file).
The playback length of original PCM input is reported as 44.120s
in audacity, so I guess its close enough to the reported output of opusinfo
?
The difference with opus_demo is explained above, and the issue affecting FLAC input files has been fixed in ecd50e531fbf378499a3f71cdca05ad969c2e29f.
I just learned about opus. A simple problem is that I use opusenc to encode a PCM file into opus file, and then use opusdec to decode the opus file into PCM. The difference between the two PCM files is not big. But I use opus_demo repeats the above operation, and the decoded PCM has a few milliseconds less tail than the PCM before encoding。