hangup when trying to play compressed [looped] wav data beyond the end

[FEBuilderGBA]

Hello. I hack FE8. I also making on a tool called FEBuilderGBA.

I'm trying to use your m4a_hq_mixer to achieve DPCM in GBAFE. I think your DPCM is a great feature because it can halve the wave capacity. If use this, I think that it is not impossible to use voice data and music in wav.

I have now gotten your routine to work in GBAFE. The compressed wave is also playing correctly.

However, there are two problems. The first is the end of the compressed wav.

The first is that it hangs if I play past the end of the compressed wav. To avoid this, you need to issue an EOT in the score to stop playback before you reach the end. In vanilla, the sound will automatically stop when it exceeds the tail.

The next issue is that we don't know the data length. We know the size before compression, but we don't know the size after compression. DPCM is said to be lossless compression, so although it is possible to guess the data length by calculation, I don't think it is a good method. We need to write the data length in the header or define the end data.

And if the data length is known, I think it is possible to stop instead of hang.

What are your thoughts on this issue? I would appreciate your reply.

[laqieer]

1. According to the codec & decodec process, it can stop at the end without the compressed data size
2. The compressed data size = 33 x ⌈ the size before compression / 64 ⌉

[laqieer]

I think it is caused by https://github.com/ipatix/gba-hq-mixer/issues/6

R5 is overwritten so it cannot enter C_channel_init_comp branch but fall to C_channel_init_noncomp branch instead.

[ipatix]

Is the compressed data length aligned to a length of 64 samples? Because I'm aware that other wave data should not work correctly yet. This is mainly due to compressed blocks always being decoded and played as a single unit.

If you use wav2agb, this should not be a problem because it does this alignment for you and correctly calculates data size.

The DPCM compression, btw, is not lossless. The delta samples only have a resolution of 4 bit and there will be quantitzation error. I do not recommend to use it as it is for "high fidelity sound". If you want better quality you might have to adapt the block decoding to something like IMA-ADPCM or something else that sounds better. You'll also have to write your own compressor in that case.

[FEBuilderGBA]

I can present reproducible data. you can ups to be deployed with FE8U. https://cdn.discordapp.com/attachments/171833225944104961/894909144157548584/pack.7z

Video https://cdn.discordapp.com/attachments/171833225944104961/894905176610197544/1.mp4

Play Song 1 in Soundroom. It takes about 1 minute to finish the song, so please skip the frame. A freeze will occur when you reach the end of the song.

In video.mp4, there is a video of the moment when it freezes. It takes time, so it is recommended to skip it by skipping the frame of the emulator.

The data you are inserting is test_compress.dmp. This is a compilation of test_compress.s. test_compress.s is created using your wav2agb.

The data before compression is song.wav. Don't worry about the content of this song. :D

The score is as follows. score01.s

song01_001:
@ 000   ----------------------------------------
 .byte   VOL , 127*song01_mvl/mxv
 .byte   KEYSH , song01_key+0
 .byte   VOICE , 0
 .byte   TIE ,Cn3 ,v127
Label_0_545B95:
 .byte   W96
@ 001   ----------------------------------------
 .byte   GOTO
  .word Label_0_545B95
 .byte   FINE

To avoid this phenomenon, we need to issue an EOT before reaching the end of the song. But in vanilla, that's not necessary.

[ipatix]

Oh, the looping is the problem. This is unfortunately something that I haven't implemented yet and it will break. Sorry for the inconvenience.

[FEBuilderGBA]

For the time being, even if you change 0x40 to 0x00 as shown below, problems will occur, so I don't think it's a loop problem.

from

    .byte   0x1, 0x0, 0x0, 0x40
    .word   0x007D0000  @ Mid-C ~8000.000000
    .word   0, 716740

to

    .byte   0x1, 0x0, 0x0, 0x00
    .word   0x007D0000  @ Mid-C ~8000.000000
    .word   0, 716740

[ipatix]

Huh, I'll investigate that.

[FEBuilderGBA]

https://cdn.discordapp.com/attachments/171833225944104961/895006116918988851/Clipboard01.png

The data of ups is as follows, and loop is not specified. At least I'm not going to specify it.

How can I make it music stop instead of hang-up after the end of the song, like a vanilla instrument?

[FEBuilderGBA]

thanks. I apologize for the inconvenience, and thank you for your cooperation.

[ipatix]

I cannot reproduce this outside of your game so it might take some time to figure out what's causing this. On my own test ROM, which uses the exact code from the repo, the song stop normally as it should.

[FEBuilderGBA]

Which game are you testing in? Would you please give me the ups?

I also want to know what the problem is.

[FEBuilderGBA]

If it works correctly in your environment, I think it's a problem with FE8 or my way of inserting data.

[FEBuilderGBA]

I found the cause. This is my mistake. Your code is not wrong.

I made an installer for m4a_hq_mixer based on Improved Sound Mixer. However, since m4a_hq_mixer has larger code than Improved Sound Mixer, I had to increase the number of bytes to copy to RAM. And unfortunately, the routine to adjust the end of the compressed wav song was placed at the end of the code. So that part of the code had not been copied and was in a mass of nop(0x00 0x00...), which resulted in the code running out of control.

https://cdn.discordapp.com/attachments/171833225944104961/895122048051982406/Clipboard02.png

https://cdn.discordapp.com/attachments/171833225944104961/895122077651173376/Clipboard03.png

This was a bug that I caused. I apologize for the inconvenience.

[ipatix]

I'm glad you we're able to find the issue!