.ADX encoding loop / DC

[VincentNLOBJ]

Regardless of specifying loop points or not in .WAV via SMPL chunk, the resulting ADX won't loop on Dreamcast.

[Youjose]

Hello, thanks for reporting the issue. I am missing some of the details of whatever the original game is. Wish you can send me a sample ADX file from the original game, and the script you used to convert it.

PS: ADXPlay (library used by criware for ADX playback) is in itself feels uncomplete. So there could be many possible option for why this wouldn't work. Possibly AINF/CINF information needed with the ADX or possibly more.

[VincentNLOBJ]

Sure,
Here's the official tool to encode Wav-->ADX on Dreamcast / Naomi:

https://github.com/Kochise/dreamcast-docs/blob/master/SDK/EXES/INSTALL%20KATANA%20SDK/INPUT/R10.1_000518/Utl/Gfx/Conv/Movie/ADX/adxencd.exe
To Auto-loop just set the argument: -lpa or specify samples.

An example of looping / not-looping ADX:
https://mega.nz/file/Ozx2lLoB#3tpclurtf96y1iAt6764XbG8PGGRfluPVOf195lOKX4

[Youjose]

Alright, so I went and fixed the ADX decoding after discovering I couldn't decode looping ADXs with it. The encoding actually works well, and matches with "Adxencd" on the Dreamcast on all counts except one: "Dataoffset". As far as I know this actually has no effect on the result. Except in one possible edge case, possibly the dreamcast's "ADXPLay" checks the size of it to set the looping flag.

Try the new patch and see if it works, make sure of couple of things:

from PyCriCodecs import ADX
wav_bytes = open("wav_file.WAV", "rb").read() # To be a looping WAVE, it *must* have a SMPL chunk.
adx_bytes = ADX.encode(wav_bytes, AdxVersion=3) # The ADX files you sent are using version 3, this usage was specified in the wiki.
open("adx_file.adx", "wb").write(adx_bytes)

Mainly the presence of a SMPL chunk, and the specification of "AdxVersion" parameter.
Try this and tell me how it goes. If it still didn't work, I will bring back the option to set the DataOffset again through parameters, I removed it a while ago for a reason I forgot by now.

[VincentNLOBJ]

Unfortunately it didn't work, the ADX is completely silent in game.

[Youjose]

I published a new update that I lazily wrote in the past weeks due to being busy, in the sample provided it works well on setting the loop points. The bug was on writing the loop values wrong, in offset and in value. And those now should be resolved. Install again and try, tell me how it goes.

[VincentNLOBJ]

Albeit audio plays, it does crash on loop.
I think it has to do with data alignment (start / end) not to 0x800.

[VincentNLOBJ]

Adding up to data alignment with header changes to 0x800, the file works.

A couple of observations to note by checking several DC ADX v3 examples:

When loop start is set to 0:

• Audio data starts always at 0x800
• File end data alignment to 0x800.
• Loop End Byte Index (at 0x28 offset) increase according to Loop End Sample Index (at 0x24 offset) by 0x12 when reaching next 0x20 samples.

i.e:

Loop end sample position : `0x1` smpl
Loop End Byte Index: `0x812`

---

Loop end sample position : `0x21` smpl
Loop End Byte Index: `0x824`

I may suggest to test adxencd.exe test.wav -lps0 -lpe100 to check it out with official SDK tools, especially for when loop starts from 1+, audio start seem to shift.