Technictix (PS2) music ripping problems by JacintaB19 at 5:18 AM EDT on July 5, 2020
Yes. I have installed WinRar, and i have ripped all of the first game's sound data by now using your BMS script, but I might be having trouble. The music has to be just right like in the actual game itself.
When I play the music in MF Audio with 12000Hz as the default (and common) frequency, the parts of each track are all jumbled up! It's almost like i've mixed up the parts of a track or almost all tracks, or have done something wrong. Track c00 has this issue along with the rest of the .mus files. There is also some stuttering while I'm playing the files. All of this might be because I haven't done the extracting correctly, as i'm not good at ripping music from PS2 games...
Why are all the instuments and sounds are put into single .vb files? Could this game have sequenced music.
The same thing also happens on Street Fighter EX3 (as that game was already ripped). There are .mus, .seq, and .vb files, but Street Fighter EX3's gamerip has .txth, and .txtp files. What do these files mean, and what are they for?
Someone might have used Cheat Engine to complete the SF EX3 gamerip. Should i do the same for Technictix?
Here's the first game's folder for your checking. The data is in the "snd", seq, and "zmus" folders. Not sure about the other folders though. The game's working title name was Symphonix.
So, i need some more help as this gamerip is harder than I've thought.
Long time no see! There is no stuttering in the .mus files. As per this post, .mus files need either descrambling, a custom playback driver, or a multi-txth/txtp per-track. I encountered this similar phenomenon with the super DBZ PS2 games. You say SFEX3 has also this very same scrambling/jumbling issue? So they use the same sound driver then.
Edit: I tested .mus with PCMLE16 .txth. I mistook stutter with jumbling. The stuttering in your extracted files must be either due to bad extraction, or incorrect source files.
Edit2: I realized the stutter's origin. You extracted PS2 files as RAW (2352 B/sect). You should extract them as DATA (i.e. iso mode/ 2048 B/sect). PS2 game media do not use ECC bytes. Extract the files with this consideration, redo the audio extraction process as you did, and the stutter should be no more. Do this for ALL your rip. Remember: PS2 media do not use ECC.
Oops! I'll have to wait until a pro like you can rip all of this game's music.
I also noticed that the script has been updated. So you can get both Technictix and Technic Beat's gamerips (as no one has ever done gamerips of these two titles).
How can i extract the files as DATA? Can you give me some tutorials for this.
"How can i extract the files as DATA?" That's my complicated way to call "copy files". In short: - Extract as RAW == use specialized CD ripping tools (isobuster, etc), or VGMt's ISO/Archive Extractor "Extract RAW to ...". - Extract as DATA == a simple "copy to" (if source files allow for copy), i.e. just copy the files to somewhere.
Extracting as DATA means to COPY the files as the O.S.'s file browser sees them: - Open game disc in file explorer (windows or linux, or your O.S.), and COPY the source (.DAT) files. None of "disc ripping" or isotools or bin extractor or the like; or - VGMt -> Misc. Tools -> Extraction Tools -> Generic -> ISO/Archive Extractor : right-click on file(s), then "Extract to subfolder", NOT the "Extract RAW to ..." options.
Then, use the .bms script on those .DAT source files as you did before. To test .mus files, use a .txth file with "codec = PCM16LE" and "sample_rate = 24000" Do this first to see if the extraction went well.
I have a problem in ripping the music from the first game. I get this error: "Incomplete output file. Can't read 14336 bytes from offset 0c103000.", meaning that it's ripped 99% of the mus files, but it can't rip the "stb and "sta" mus files in the "zmus" folder (It can rip the folders if the data is RAW).
Really? I think maybe the .bms is made to read from CD drive, and that could be why there is additional data (useless for playback); the .bms author could give insight on this. Or maybe the .bms script needs ALL of the files from the disc image, so then you would copy ALL the files on the (virtual) drive, to some folder where to be extracted with the .bms. Maybe you are reading the .DAT files from virtual drive software? .bms scripts by default read data as it is read by the O.S., i.e. as "DATA" and not "RAW". Some software could present issues with the way CD/images are read. Otherwise, as the .bms script does read input files as DATA, your best failsafe test would be to simply copy ALL the files/folders in the disc (image) to some folder, and apply the .bms script there instead. By now, you SHOULD have an idea of how to create .txth files, based on your past posts.
Sample .txth file for the .mus files. By the way, how did re-rip go? Did you get proper .mus files this time? If it's too much work, you can upload the source files to extract the .mus data and others.
Teh.. source files are the files which might contain the sound data (i.e. the source of the sound data). PS2 gamerips, I understand them as "(PS2) CD/DVD data rips", am I correct? If that's so, then just upload the files contained in the CD/DVD images.
Edit: when I said "re-rip", I meant updated folders & files in your (?) g-drive, because those were ripped in RAW mode instead of DATA mode. PS2 rips do not use ECC (afaik!), so for every 2352 bytes of data extracted (in RAW mode) from CD/DVD, only 2048 bytes = 2 KB are significant DATA (the rest are ECC bytes as well as other data. The files in your original (game)rip in your folders show that there is RAW data in them, that's why the .mus files (in zmus folder) sounds with the stuttering.
If CD/DVD dump is .bin/.cue pair, then it's "RAW" (.bin contains RAW bytes); if it's one .iso file, then it's "DATA" (.iso contains DATA bytes). Obviously .bin/.cue is more "exact", BUT this is not needed (afaik!) for PS2 CD dumps. As this game's media is CD, then "DATA mode" dump is just an .iso dump. A .bin/.cue dump (i.e. "RAW") contains extra bytes, which might have interfered with .mus extraction. ... If you have the game CD dump, just upload it here.
Yes! The files are correctly ripped this time. Well done! All DATA as it should be. Do NOT forget to prefix a dot "." befote the .txth file. This must be ".mus.txth" (with the leading DOT !!!). Put the .txth file in the same location as the .mus files (for both games), and play them with vgmstream. You will notice the "jumbling" pattern cleanly in the .mus files.
Warning! In "Technic Beat (PS2) Dump" folder, from \zmus\ste\e21.mus to e32.mus and folders stf,tra,trb,trc,trd,tre,trf, .mus files are "empty" (no data, i.e. "0x0"). A re-rip is advised (bad copy or interrupted dump).
I'll need to find a good copy of Technic Beat, then for the re-rip, which will take forever.
I've just got all the music for the first game, but as you said, the .mus files have the jumbled pattern. I need help on getting all the tracks to sound right like in the game (and on it's soundtrack album) with all the right patterns for all tracks.
We would need to study the .seq/.mex/.mrk, to combine them with the .vh/.vb and "mix" them into the descrambled .mus, in order to get music as in the (proper) OST. The .mus files only contain background music, while the .vb files contain the instrument samples as played in-game. The music data should be in some .DAT files (according to .bms script), please upload it/these here, I do not believe you need to find a "good" copy if you have the game. The "null" files look like the .bms script got in trouble, or there was a file read error on your side. These failed-to-extract files seem indicative of missing (music) tracks.
I rerip Technic Beat's data using some .iso rip from the web. The .mus files are extracted using AnonRunzes's qbms script. I edited a few lines in this script in order to accept the game's ELF file as input.
So, we got the .mus files already, but they will not play right! Using useful info from permic(2)'s post, I figured some algorithm that hopefully could be implemented in vgmstream:
channels = 2 ## default; or =4; ## input, maybe from source data/executables interleave = 0x17700 ## input, as above
## The .mus files are arranged such that playback is as follows:
## Let (block) be the nº of bytes of data separated by 0x200 (default 2-channel), encompassing all channels as audible by testing: block := 0x2F000*(channels/2);
## Thus defined this block like this, it represents a portion of time (2.000.. seconds) in the music track.
## Let NN be the nº of these chunks: NN := data_size / block;
## Let's index these blocks as 0, 1, 2, ... NN-2, NN-1. ## Then, if (NN is even), play order would be: 0, 2, 4, ..., (NN-2); (NN-1), NN-3, NN-5, ... 1; ## Otherwise, if (NN is odd), then play order would be: 0, 2, 4, ..., NN-3, (NN-1); (NN-2), NN-4, ... 1.
## The playback method would be something like this:
if (NN % 2 == 0) ## (NN is even) { NP1 = NN - 2; NP2 = NN - 1; } else ## (NN is odd) { NP1 = NN - 1; NP2 = NN - 2; }
i = 0; while ( i <= NP1 ) { play [interleave] bytes from offset [i*block] & send to channel 1; play [interleave] bytes from offset [i*block + interleave] & send to channel 2;
if (channels == 4) { play [interleave] bytes from offset [i*block + block/2] & send to channel 3; play [interleave] bytes from offset [i*block + block/2 + interleave] & send to channel 4; }
i += 2; }
i = NP2; while ( i >= 1 ) { play [interleave] bytes from offset [i*block] & send to channel 1; play [interleave] bytes from offset [i*block + interleave] & send to channel 2;
if (channels == 4) { play [interleave] bytes from offset [i*block + block/2] & send to channel 3; play [interleave] bytes from offset [i*block + block/2 + interleave] & send to channel 4; }
That way we would not have to configure many .txtp/.txth combinations for all the .mus files! Also, these files will not need to be rearranged/"descrambled" with this implementation.
The post above was really helpful, thank you almendaz !
I've made a simple Script in python that makes playable .WAV files based on your algorithm (which still isn't enough for a proper gamerip since it lacks the samples from the .VB files, we'd need to understand the .seq and .mrk files for that I guess ?)