I was trying to use your OggMuxer but I encountered an issue with audio duration, which is consistently displayed to be 1/3rd of the correct one. Even if you are not actively thinking of fixing this code, I'd love a response to pinpoint whether this is actually the issue at hand. Unfortunately, I am not entirely familiar with the OGG specification, so I cannot say that this is the issue with 100% certainty, but I think it might be because your granule position code is not taking into account the opus packet code that is received (and thus the number of compressed frames in each packet):
In my case, the first two bytes I receive from my opus source are 01111011 10000011.
Hence, the packet code is 0b(11) = 3 (the last two bits of the first byte) and the number of frames is also 3 0b(000011) (the last six bits of the second byte), which would explain why my duration is always 1/3rd of the correct one.
If you know this to be the case, I'd gladly open a PR (should be a pretty easy fix, even for code 1 and code 2 packets :) ). Thanks!
Hi!
I was trying to use your OggMuxer but I encountered an issue with audio duration, which is consistently displayed to be 1/3rd of the correct one. Even if you are not actively thinking of fixing this code, I'd love a response to pinpoint whether this is actually the issue at hand. Unfortunately, I am not entirely familiar with the OGG specification, so I cannot say that this is the issue with 100% certainty, but I think it might be because your granule position code is not taking into account the opus packet code that is received (and thus the number of compressed frames in each packet):
const newCount = packets.reduce((acc, val) => acc + sampleRate * FRAME_SIZE_MAP[val[0] >> 3], 0);I report here the RFC figures for both TOC and Code 3 packet frame count bytes as reference:
In my case, the first two bytes I receive from my opus source are
01111011 10000011.Hence, the packet code is
0b(11) = 3(the last two bits of the first byte) and the number of frames is also 30b(000011)(the last six bits of the second byte), which would explain why my duration is always 1/3rd of the correct one.If you know this to be the case, I'd gladly open a PR (should be a pretty easy fix, even for code 1 and code 2 packets :) ). Thanks!