Output WAV still seems to have problems if there's loop header section

[segfault-bilibili]

• Fix offset miscalculation bug

Should be within this function: https://github.com/segfault-bilibili/DereTore/blob/c364976c6e38fb128dccab3aed1d3caf888114a8/Exchange/DereTore.Exchange.Audio.HCA/HcaDecoder.cs#L23

I probably know what's going on. GetMinWaveHeaderBufferSize() added the size of WaveSampleSection to the total header size. Then such WAV header probably failed to be written, which should be the unexpectedly inserted dozens of zero bytes, which will then confuse WAV parser/player.

However I still don't understand why the size recorded in WAVRIFF header doesn't seem to include WaveSampleSection... Now I just hesitate to write WaveSampleSection - I don't know what this section is for, a simple solution would be just comment out that if (hcaInfo.LoopFlag) {...} lines in GetMinWaveHeaderBufferSize. Copied what https://github.com/segfault-bilibili/hca.js is doing, won't hurt at least...

---

- [ ] Re-decode the "seam" block maybe this is not needed at all. Related: Nyagamon/HCADecoder#4

[segfault-bilibili]

I see "unknown chunk" after PCM sample data. I don't know what it is, but it doesn't seem to disturb anything...

[segfault-bilibili]

Ah, the same bug I had once created & then fixed😂

segfault-bilibili/hca.js@3804499

Oh, I need to confirm this... Confirmed.

[segfault-bilibili]

At least the "seam" block (at the start of looped blocks) itself should be re-decoded. I'm not sure whether more blocks should be re-decoded, however the affected bytes don't seem to be enough to make a full block - in other words, reworking one block seems to be enough to make the output byte-to-byte exactly the same to "stupidly" decoding every block including looped ones.

Oh, I need to confirm this... Confirmed.

[segfault-bilibili]

Still not sure what happend, but something must be wrong - I tested with an HCA with its loop section stripped, and then the output WAV file seemed to be normal this time, without weird "unknown" chunk at the end.

What makes this an issue is, this seems to be caused by dozens of zero bytes inserted in the middle of PCM data...

The WAV header part is the same - which means the offset/size value written to the header is correct, then probably the writing offset(s) is miscalculated. See updates in the top post.

[segfault-bilibili]

Oh now we have two bugs😂