SomeHumanPerson wrote: ↑Tue Jul 25, 2023 7:02 pm
When you say "entire stream", this must be limited per individual piece/file, right?
It's not clear. The calculation must be reset at the joints, but it seems that the check of all previous data is made at the double major before it is reset. Exactly how the seamlessness works is still unclear to me. In some CRC implementations initialization involves setting the sum to 0 and then updating twice before going into on-the-fly single updates at the single majors. Here's where it is interesting: there is a double major at each cut point, so it looks analogous. I'm still looking into this, but not too seriously because I think these failures are not the root cause for the Atmos dropouts with AVRs.
So your gap correction technique has avoided any lossless check violations up to this point because you trim at the end of the previous piece/file, and then the next piece/file "starts over" in terms of the lossless check?
No. The gaps correction
does cause lossless check errors. I may have been unclear about that. But it is not an issue for transcoding. And now I believe it is not the root cause of the dropouts with the AVRs, but rather loss of data in the 4th (Atmos) substream. Without knowing more intimate details about Atmos encoding and decoding, I'm pretty much stymied. The reason I no longer think it's the lossless check failures is because they do not seem to affect decoding (e.g., with VLC etc.), and because
horseshower's dropouts occur only with Atmos and not simple TrueHD.
Do you mean here that you know exactly what the lossless check entails and can re-calculate to "forge" a new major with the corrected result? Does the check use a simple hash of some kind?
The parsing and handling of the lossless check can be seen in Ian Caulfield's ffmpeg support for TrueHD. His code is also valuable in filling in missing info in the MLP spec. The check is a running CRC-32 down-converted to 8 bits and compared to the lossless check field in the major frame's restart header. That much is clear. Ian's decoder reports the failures but that's all; it doesn't stop decoding or invoke any recovery process. Yes, the forging was an idea but I no longer think the lossless check failures are the root cause. Note that Ian's code ignores the 4th substream so it does not support Atmos for transcoding. Anyway, you can't put Atmos into (say) FLAC.
I see all over the web cases of Atmos dropouts, even for linear play with no cutting. I'm ready to admit defeat. The
thdtrim utility may be useful for transcoding in some use cases, but the cutting would be more appropriately done in the uncompressed domain, given that we don't know how to salvage the Atmos.
Well, that's my current thinking. I don't see any forward path at this point. But prove me wrong!