Can't import OPUS audio into Audacity and Windows shows media length is 0s

[stodge]

I copied the code to encode to an OPUS audio file from the following link. The audio file will play back in Windows, and I think it sounds correct. However, Audacity won't import it (incorrect filetype, even though the file extension is ".opus") and the properties for the audio (via the file explorer) show the media length is 0s.

https://github.com/lostromb/concentus/blob/master/Java/ConcentusTestConsole/src/main/java/org/concentus/console/Program.java#L24

It occurred to me that the loop doesn't process all bytes from the input stream.

while (fileIn.available() >= inBuf.length) {

It misses a number of bytes. After the loop is done, there are still bytes left in the stream:

fileIn.available()

Results in - Available: 1836

I tried encoding the remaining bytes after the loop, but I got an error:

Exception in thread "main" java.lang.IllegalArgumentException: Not enough samples provided in input signal: Expected 960 samples, found 918

Any suggestions appreciated.
Thanks

[lostromb]

Yeah, the java test console is really not robust so it'll ignore the last few milliseconds of audio, among other things. You could pad the input data with zeroes, or really the more correct approach would be to implement gapless playback at the end of an opus file - except that the spec for that is so vague that I haven't even been able to understand it.

The big problem here is that the Ogg containerization is handled by an external library VorbisJava, and for some reason it doesn't seem to update granule positions correctly for Opus packets - these are timing signals that indicate the playback time each opus frame corresponds to. Since all granule positions are set to zero, many playback tools say the file format is invalid (VLC player, Audacity, others...), or at the very least they play back with file seeking disabled as Groove Music does.

We can work around it by writing the granule position directly, but this messes up the Ogg paging somehow. While the resulting output files are compliant with the spec and play back correctly, they have a huge amount of Ogg overhead because it generates a new page every 20ms instead of every few seconds as expected. This should be a bug on VorbisJava.

[lostromb]

PR #49 for the "working" code

[lostromb]

Ah, and it seems this bug has already been reported #23. Apparently if you pull the latest vorbis-java master code and compile it yourself, the granule position bug is already fixed. It's just not in Maven.

[stodge]

Ah, and it seems this bug has already been reported #23. Apparently if you pull the latest vorbis-java master code and compile it yourself, the granule position bug is already fixed. It's just not in Maven.

Thanks for fixing this, it's very much appreciated.

I'll grab the latest vorbis-java code and try it, hopefully early next week.

[andrm]

I did a few opus contributions to VorbisJava back then, and my code was wrong initially I think. It got fixed and now it should do the exact same thing as opusinfo when reporting properties of opus files.