@draeath @fasterthanlime I've worked on codecs (not these ones): there are technical reasons for this to be the case - the filters that are used to decode an encoded audio stream, among other things, use overlapping techniques (probably something like an MDCT or ELT) which means the first outputs from said filters are necessarily going to contain unusable data.
Because of this, many (most?) codecs have some kind of priming scenario at stream start where zeros are fed into the filters to get them rolling, so that the first real audio data to go in will come out at the beginning of the first "meaningful" output sample. But since most of these filters are written as roughly "put N samples in, get N samples out" (it's not quite that because the input is in frequency domain, but close enough), the first batch or two have to be discarded by the code (somewhere) as they won't contain usable audio.
It sounds like this particular implementation just didn't do that part properly
=> More informations about this toot | View the thread | More toots from JoshJers@peoplemaking.games
=> View draeath@infosec.exchange profile | View fasterthanlime@hachyderm.io profile
text/geminiThis content has been proxied by September (3851b).