I'm currently reading the opus in ogg specs to find out which tool is buggy (and whether files like RObV6XA0h1k.opus are actually against the spec (there might be a reason that opusinfo only shows a warning for such files)) and inform the relevant people. So you don't need to try other files from the site again. Unfortunately the invalid samples with negative timestamps aren't stripped away later either: If you output it to wave, the wave muxer includes the invalid samples in the output file and if you reencode an opus file again (using ffmpeg's native decoder and the libopus encoder) the output file causes opusinfo to raise a 'Samples with negative granpos in stream 1' warning and mkvmerge includes these DiscardPadding elements in the whole file. And the first opus file you uploaded (wNs6w3z.opus) was created using libavformat, ffmpeg's muxer and demuxer library.īut anyway, I can now produce such files myself: As has already been mentioned, ffmpeg's native opus decoder doesn't strip the Preskip/CodecDelay away instead it adapts the timestamps: The first pcm sample has a timestamp of -312 (if the preskip was 312 samples, the default for libopus) on an 48 kHz timescale (or -6.5ms if you prefer) so that the actually valid samples start at zero. Lavc stands for libavcodec, the library ffmpeg provides for de- and encoding. You have definitely already used ffmpeg: XMedia Recode uses it in fact, RObV6XA0h1k.opus was created by ffmpeg: Lavc58.17.100 libopus encoded RObV6XA0h1k.opus. In particular I'd like to know if you can reproducibily produce files like A.

Given that A is likely buggy I'd like to know exactly how you created it. Unfortunately I don't know an analyzer that does for ogg/opus what mkvinfo does for Matroska.ĥ. The differing behaviour of the reference decoder and mkvmerge might be due to a bug in the latter.Ĥ. If A is decoded with ffmpeg's native decoder then it is quite ok (the native decoder doesn't strip the CodecDelay away, so that the output file is actually 624 samples longer than the output of the reference decoder). 443s = 7m23s, the length of the file is about 7m24s. Consequently the decoded output of A and B diverge gradually the difference in length is 138216 = 443*312 samples. When A is decoded with the reference decoder, it also has this popping in it, but only once at about 970-980ms B has it more often, because it has DiscardPadding elements every second. (These are the errors that opusinfo outputs if one extracts the track from B to ogg/opus and analyzes the output with opusinfo.)ģ. What is remarkable is that there are no 'WARNING: Sample count ahead of granule (49920>49608) in stream 1' and no 'ERROR: stream 1 has interior holes or more than one page of end trimming' messages. The second warning is an obvious result of the fact that the file is truncated I don't think the first warning is, but to be sure I'd like to check the whole 33MB file. WARNING: EOS not set on stream 1 (normal for live streams) opusinfo has two complaints about B: WARNING: Samples with negative granpos in stream 1 A uses page durations of 1s and the DiscardPadding elements in B are attached to the last frame out of A's pages (if I am not mistaken).Ģ. I can confirm that in B the packets at 980ms, 1980ms etc.

Thanks.įor ease of reading: A = the opus file you just uploaded, B = file A remuxed with mkvmerge, C = file A remuxed with ffmpeg to opusġ. If you have no problem uploading the whole sample, then please do so.

Mkvtoolnix gui preview