News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: PC Engine Ripping voice clips and PSG music  (Read 1910 times)

apraxiumRum

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
PC Engine Ripping voice clips and PSG music
« on: September 24, 2019, 01:08:55 am »
I've been tinkering around the PCEngine CD (Still trying to make translation for Dragon Slayer: The Legend of Heroes II  :P).
So far I found some promising stuff: Using TurboRip to get the "ROM" for the game and the WAV tracks (The lines and text are actually not encrypted!). But I am stumped about the thing that been bothering me: the voice clips.
How can they be ripped? I've heard a lot of Ys IV's dubbing job, yet I never found how it was done. The only voice clips I found were in the Opening and the Ending tracks. I am guessing they are with the PSG music tracks (that ripping never reveal them).
How it can be done? And replaced back to the ISO after dubbing? I know it too early to think about, but I want a headstart to know at least what to do.

julayla

  • Full Member
  • ***
  • Posts: 198
    • View Profile
Re: PC Engine Ripping voice clips and PSG music
« Reply #1 on: September 24, 2019, 12:15:39 pm »
To be honest, I would like to know how it's done as well. I mean if done correctly, you can actually use either different music or a different language dub this way like what the Ys IV dub did.

dshadoff

  • Full Member
  • ***
  • Posts: 157
    • View Profile
    • Homepage (really old)
Re: PC Engine Ripping voice clips and PSG music
« Reply #2 on: September 24, 2019, 07:00:49 pm »
I wrote some ADPCM extraction/re-insertion utilities many years ago, and they have been used in a few places (Ys IV, Dracula X, etc.).

You can find them available for download here:
http://www.ysutopia.net/index.php?ind=downloads&op=entry_view&iden=5
(If source code isn't included and you need it, let me know)

Note: each message is embedded in a data track, which will also have code, graphics, etc.; the utilities work based on the offset inside the track.  If you don't know the offset, you may be at a disadvantage.

There is a way to roughly locate the messages, and that is to decode the entire data track, and listen through the noise until something intelligible comes out.  When it does, you will know (a) the existence of the message, and (b) based on the time signature, the rough location within the data track.  This should easily work back to an offset, since ADPCM compresses the amplitudes, not the samples themselves - time offset within the track remains a fixed ratio to location offset within the track.

Dave

apraxiumRum

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
Re: PC Engine Ripping voice clips and PSG music
« Reply #3 on: September 25, 2019, 08:30:37 am »
Thanks dshadoff! I guess its all within the datatrack2.iso me think.
I may indeed have a disadvantage with the whole offset thing. I haven't grasped the concept of pointers in general.
Regarding decoding, is there a way to listen to the datatrack in its .iso form?

dshadoff

  • Full Member
  • ***
  • Posts: 157
    • View Profile
    • Homepage (really old)
Re: PC Engine Ripping voice clips and PSG music
« Reply #4 on: September 25, 2019, 10:28:07 pm »
Regarding decoding, is there a way to listen to the datatrack in its .iso form?

I'm not sure what you mean here...
When you say "in .iso form", are you talking about a track-by-track, or a full-disc image ?
In order to do anything, you would need to start with track files - most will be simple audio (CD audio tracks), but some will be data tracks (2048-byte MODE 1).  a full disc image will add all sorts of ECC error checks data which just confuse things.

Once you have a CUE/track extract, another more accurate way to find the locations of the ADPCM data, is to use the Mednafen debugger, and keep track of data loaded into ADPCM memory (and played); you would also need to keep track of which sectors are loaded from disc into memory too.

Many people might find this boring, tedious, or too much work - but it's the best way to have a full working knowledge of the system, and get accurate lists of memory locations where messages reside in the data track.