Issues with handling the .HSB format used in Resident Evil 1

[Rarefoil]

Describe the bug To start off with, VGMTrans cannot properly extract the sound samples from the HSBs (specifically, the VGMSampColl files it finds). While it can complete the operation to convert to WAV successfully, the result is almost always crackles and bleeps. Sometimes it gets really close, but most of the time, crackles and bleeps. This afflicts also playing the PS1 SEQ file in the program and the .sf2 files it makes from the .VAB files also in the .HSB files.

The main issue is that it sometimes fails to find a PS1 SEQ file when all logic says there is one. After going through all the .HSBs in the SOUND folder, there were several songs from RE1 that I simply didn't find the SEQ file for. Additionally, a few .HSB files clearly have samples meant for music*, but all VGMTrans shows is a VGMSampColl file and a VAB file.

I'll admit that there's a possibility with the last one that I'm simply mistaken and the .HSB files do just not have SEQ files, but at the very least, the sound samples are a legit bug. And I can find unaccounted-for data in SEP20.HSB files when looked at with a Hex editor.

To Reproduce

1. Start up VGMTrans
2. Load any of the following files, copied directly off of the RE1 Disc (Location: PSX/SOUND):

• SEP20.HSB
• SEP22.HSB
• SEP25.HSB
• SEP26.HSB

3. Find there is no PS1 SEQ file listed.

For the sound sample issue:

1. Start up VGMTrans
2. Load up any .HSB files copied from the RE1 Disc (Location: PSX/SOUND)
3. Load up the VGMSampColl file and try to play a sound
4. Convert all the samples in the VGMSampColl into WAV and try to play them in any audio player.

Expected behavior VGMTrans plays a sample correctly and find either 1, 2 or 3 PS1 SEQ files in the .HSB

Desktop

• OS: Windows 10 Home 64-bit
• VGMTrans version:
  • 1.0.0.1 according to the Properties
  • VGMTrans Interim Build (2017-02-25)
• VGMTrans log: N/A
• Resident Evil: Director's Cut (not the DualShock version), NTSC-U/C, direct file copy to Windows: SLUS_00551/90009

Additional context VGMTrans also says there isn't a PS1 SEQ file in SEP1F.HSB When VGMTrans loads a .HSB file directly from the disc when it's inserted into the drive, it operates exactly the same.

*When I open the .HSB files in PSound, the samples are far more accurate and I can find several samples in SEP20, 22, 25, and 26 clearly meant for instruments (strings, drums, and brass). SEP1F only has the one sample and sounds like a sound effect.

[Meerkov]

Hi, Please confirm that you aren't using a file with Error Correcting codes in it (sector size 2352 instead of 2048). This is a common issue, so I thought I'd try to help

[Rarefoil]

Thank you for replying and sorry I couldn't respond more promptly.

However, I must confess I am unsure what exactly you are referring to. I do know of the general concept of Error Correcting codes (adding extra bits to data to ensure proper transfer), but how this could be affecting the files and what I could do about it I am not 100% sure.*

Additionally, I have plugged the files I mentioned into another VGM ripping program (VGMToolbox), and I did get PS1 SEQ files from them; most of them even were read properly by VGMTrans (but there was always one it couldn't). And considering all my other .HSB files from RE1 have shown PS1 SEQ files, and these were all block copied, it doesn't feel like the files are the ones at fault.

However, if there's just something I'm missing, please don't hesitate to inform me.

I've also discovered some new data/errors concerning this:

1. When these two .HSB files are opened in VGMTrans, only one PS1 SEQ file is shown:

   • SEP2F.HSB
   • SEP25.HSB

   I didn't mention it before because I thought that was normal, but when opened with VGMToolbox, 3 PS1 SEQ are produced, same as every other .HSB,

2. Concerning SEP25, there was one PS1 SEQ file that while VGMTrans couldn't read, another program could (Awave Studio) and even convert it to MIDI. It was an actual file that the game used for a sound effect, too. This does suggest that all of the SEQ files it couldn't read were properly made. I could definitely check that out later, but this is already a little too long.

3. The sound sample error turns out to affect more than the samples themselves; it also offsets them. With SEP25 (which has 11 samples), Sample 0 was interpreted as audio junk and the actual Sample 0 was labeled as Sample 1, Sample 1 was Sample 2, etc. They are more accurate, enough so that I can tell what they're supposed to be, but the end result is that the last sample is just nowhere to be found/heard since Sample 10 is actually Sample 9 and the list ends there. So the one PS1 SEQ file VGMTrans could see and play in that file had the completely wrong sample.**

Thank you for your offer to help with this.

*My best guess, based on your example (assuming the numbers represented bytes), is that you're referring to the two "Size" and "Size on disk" properties of a file in Windows 10, with "Size on disk" being bigger to account for Error Correcting codes. But, assuming I did the math correctly and the math was well founded to begin with, your example would increase the size of the file by ~13%, while when I check the size of an .HSB file, the increased size "on disk" is ~1% or ~2%, even when I'm reading straight from the CD. This includes the files that don't work properly in VGMTrans. And I don't see a way to even change the difference between the two reported sizes.

**Also, based on PSound's extraction of SEP25.HSB, Samples 6 and 7 seem to be the actual Sample 5 broken up and actual Samples 6 and 7 are either combined into Sample 8 or one is just removed. Granted this is assuming PSound is 100% accurate and working correctly too.

[Meerkov]

Oops, I'll explain what I mean more clearly:

On playstation, data on disk is split into sectors. Each sector is 2352 bytes big, but the data is usually only 2048 bytes, The difference is for the error correcting codes. MIDI files (SEQ are basically modified MIDI) will be stored in this way, because they are essentially mini programs (so even 1 wrong bit can ruin the song). As a result, SEQ files need error correcting codes on the original playstation... This format is called the RAW format, while the data without error correcting codes is the "normal" format (for the purposes of this discussion, at least).

As a result, if you're getting your files from an .iso, .img, .bin, or other CD rip format, then you've probably also got included in it the error-correcting codes.

However, VGMTrans doesn't support RAW format. Basically, no one ever wrote a thing that understands to skip over the ECC every 2048 bytes, and so what will happen is that if the ECC happens in the middle of a file, then the file will appear corrupted, and you'll see garbage output, or files will be missing (because they don't parse correctly and get thrown away by the parser). This is a common point of confusion, and it trips everyone up because VGMTrans doesn't do a good job of telling you what errors it had... But good news is that if this is your problem then there is a solution!

Long story short, try this: Download jPSXDec, and run your original cd file (the iso/img/bin) into that, and try exporting all the files from there, making sure to use "Normal" format for the files. jPSXdec understands the CD better, but doesn't understand midi... So it will export your .HSB files properly into normal mode (2048 byte sectors, no ECC), and then VGM Trans should work on those.

Edit: And based on your description, this sounds like your problem (some SEQs work, others don't. Some missing sound effects, but randomly in the middle, etc).

[loveemu]

@Meerkov I'm not familiar with CD file formats, but am I correct in assuming that if I mount the image file on my system using Virtual CloneDrive or something similar, and extract the files from there, I won't run into any ECC-related issues?

[Meerkov]

@loveemu I'm not actually sure. I think the CD error correcting code is not unique to playstation, so I think other softwares that handle CD file extraction should also work.

[sykhro]

You don't have to worry about the ECC data unless you are making a raw dump of the disk, that is, copying every single bit off the optical media.

[Meerkov]

@sykhro My understanding is that most people who use playstation disks will be making a raw dump of the disk. Or, at least, the people who are reporting issues with corrupted SEQ media on playstation appear to be suffering from this issue.

[loveemu]

Aside from the RAW image thing, I haven't had time to verify the event reported at the top.

[Rarefoil]

Thank you very much for the explanation @Meerkov . It cleared things up very well. And again, sorry for not responding sooner.

I realize this wasn't made very clear by my previous posts, but I didn't get the files from any kind of CD image file. I got them from my original, physical PlayStation CD-ROM of Resident Evil Director's Cut. I put it in my DVD+/-RW drive in my laptop and opened the contents in Windows File Explorer.

But of course, that could just mean Win10 doesn't really know how to handle the ECC stuff either, and whenever I've tried to copy the video files from the CD-ROM, it has never worked, possibly supporting that theory.

So I downloaded jPSXdec and put a .bin of that same CD-ROM I made a while back into it, selected all the files in the SOUND folder, marked "Normal" on all of them, and...

still nothing. I tried the same .HSB files, and SEP20 still has no PS1 SEQ files and SEP25 still only has the one and plays the incorrect sample to boot.

So I decided to make another .bin of the same CD-ROM but instead put the speed to 1x / 1x (ImgBurn), because I know that I had it much faster when I made the previous .bin.

Same result.

I then downloaded an .bin off the web on the hopes that maybe I was still doing something wrong and that the one off the web was far more accurately made, and said website has a very good reputation for this kinda thing.

Same result. I compared one of the resulting files between my 1x / 1x .bin and the web .bin and found they were identical.

I then got curious and decided to select the "Raw" option for one file. (SEP20.HSB from the web .bin) And the resulting file was noticeably bigger than all previous copies of that file. And when I opened it in VGMTrans, it said there was a VGMSampColl for every individual sample in the file, and no VAB or PS1 SEQ: a completely different result from all of my previous attempts to open a file, including the original copies from the physical CD-ROM.

Also, when I compare one of my original copies off the physical CD to a jPSXdec rip from the web. bin, they're identical too - except for a ton of extra blank bytes added on to the end of the jPSXdec file.

...Is there something I'm doing wrong?

[Meerkov]

Well, it sounds like actually you have a "normal" rip (without ECC) based on this. So, in that case, it probably isn't the issue I said :)