-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loop start/end position may be wrong (slightly off) #4
Comments
(Sorry for mistyping something above. Now it should be corrected) I'm not very sure which interpretation of the |
Well, think about it a little. If your first two points are true than no HCA file could have a loop that's not a multiple of 0x400. This would be extremely restrictive and result in funky loop points if they couldn't be multiples of 0x400. The structure of the loop block is
The pre-loop samples are the number of samples in the loop start frame that come before the loop point. The post-loop samples are the number of samples in the loop end frame that come after the loop point.
My decoder/encoder should be completely correct and has been thoroughly tested against CRI's decoders/encoders that are available. |
Well, actually it's not "my" point - I didn't know HCA at all until I came across https://github.com/y2361547758/hca.js, which is TypeScript port of this project (https://github.com/Nyagamon/HCADecoder). Even for now I still have no idea how stock/official HCA decoder works (which should require reverse engineering).
That's actually exactly what I had thought of. However I have been unable to imagine where the more accurate loop start/end pointers could be put at, until I came across your project (https://github.com/Thealexbarney/VGAudio). I think Nyagamon's interpretation of loop header may make some sense because every (although the number is very few) HCA (which is infinitely looped in game) I have examined seems to have |
By the way, I wonder it's signed or unsigned integers? It doesn't seem to make sense to use nagetive values here. |
I've reverse engineered the HCA encoder/decoder. The implementation in VGAudio is functionally the same as the official one is, producing the exact same data output for both encoding and decoding, so it makes a good reference. (Note: I replaced the IMDCT implementation CRI uses with a faster one. The only difference in the output from the current master VGAudio build will be due to tiny rounding differences. When using the IMDCT implementation CRI uses the outputs are identical.)
No, that's because of how the encoder works. The encoder inserts a subframe of audio at the start because decoding a subframe requires some of the data from the previous subframe. This results in the loop start being one subframe past the start of a frame since the decoder needs data from the previous subframe to decode the next one. BTW, be sure to account for the |
They're signed, but it doesn't really matter since they won't get anywhere near the limit of the signed types. |
Thank you very much!
To be honest I know almost nothing about signal processing etc... I feel sorry if my noob questions occupied your time. However these two questions should be the last ones I want to ask. Again, thanks a lot! |
Yes. This is true for all HCA files. Side thought: Oops, I just noticed that naming inconsistency public const int SubframesPerFrame = 8;
public const int SubFrameSamplesBits = 7;
Oversimplifying enough to answer your question, decoding subframe(SF) N requires only the encoded data from both SF N-1 and SF N. It doesn't need any data from any other SF, so it doesn't need data from either SF N-2 or SF N+1. For example, decoding the audio in subframe 4 requires only the encoded data from both SF 3 and SF 4. It doesn't need any data from SF 2, SF 5 or any other SF. This is why an extra subframe is inserted at the beginning during encoding and thrown out as garbage when decoding. |
Currently it seems to be:
The
loop
header section seems to be interpreted as:However, according to VGAudio:
https://github.com/Thealexbarney/VGAudio/blob/9d8f6ea04c83cccccb3dd7851a631bbd53a8dbbe/src/VGAudio/Codecs/CriHca/HcaInfo.cs#L35
https://github.com/Thealexbarney/VGAudio/blob/9d8f6ea04c83cccccb3dd7851a631bbd53a8dbbe/src/VGAudio/Containers/Hca/HcaReader.cs#L189
The text was updated successfully, but these errors were encountered: