Ripping music and sounds from Sega NAOMI arcade games by JacintaB19 at 11:06 AM EDT on May 23, 2020
I'm wanting to rip music and sounds from Sega NAOMI arcade games like the japan-only arcade version of Rhythm Tengoku. Are there any ways for me to do so?
As many file systems, there is some VFS in consideration, which needs figuring out. You examine your ROMs from those dumps, and merge them in the appropiate order. Anyway, the .bin files should contain your audio; I did not examine further. VFS for you!
I can't do this on my own. Have you gotten the music and sound files yet for me?
Also, Rhythm Tengoku was only released on the GBA and the Sega NAOMI in japan, so this game wasn't released on the Dreamcast though... Also notable for being the only Sega NAOMI game made by Nintendo.
Yes you can DO IT ! At least use the tools in the last two links I gave you. Naomi could be called "DC arcade" (purists please don't blame me, I just wanted to put it quickly), so sound in N can be ripped in the same way as DC.
If you still (...) have problems with the tool in the second link, then do the following:
1. Donload python v2.7 and install it. Also, install 7zip if you don't have it already. 2. After installing the above, download the archive from here. This contains the extraction and conversion scripts, written in python v2.7. 3. Extract the archive in some folder. Enter this folder. 3. Put here ALL the .BIN files from the game's VFS in the same folder as the extracted scripts from the archive. 4. Open a cmd window in the current folder (in the current folder, do [ALT] + [D], type "cmd", then [ENTER] ) 5. In the cmd (terminal) window, type: for %k in ("*.BIN") do python dsfdtpk.py aicadrv.bin -a %k 6. Wait (long process I presume). 7. Done.
By the way, .DSF/.MINIDSF files are playable with foobar200 with SSF/DSF decoder. You know the music, so you should tell if the music has been properly extracted/converted.
Very good that you did 1-3 on your own. Gratz! The next steps, with more detail:
4. In the current folder, do [ALT] + [D], type "cmd", then [ENTER]. ^ This means: go to the address bar in Windows Explorer, then write "cmd" there (as if you wanted to search "cmd"), then press [ENTER] key. A command (cmd) window will open in the current directory.
5. In that cmd window taht you just opened, type the command - literally: for %k in ("*.BIN") do python dsfdtpk.py aicadrv.bin -a %k ^ What this does: For every input file that has .bin extension, "python" will execute the script "dsfdtpk.py" (also in the current folder), will import "aicadrv.bin" as the (sound) driver, and will pass the "-a" parameter to the script (meaning "include sound effects and other sound data" - as a failsafe).
It is not really complicated once you get used to this. If you are into binary extraction, start learning some DOS/cmd commands.
Step 4 is done, but step 5 is much harder for me. When tried to do step 5, the files didn't convert. It gives me the following errors "python is not recognized as an internal or external command, operable program or batch file.", and "The filename, dirctory name, or volume label syntax is incorrect." What do the two "%k"s mean for this? Help!
If that does not work, then you have to call the executable by path. Locate your python.exe in your installation. Let's assume that folder location is "C:\Program Files\python". Then the command in 5. would be:
for %k in ("*.BIN") do "C:\Program Files\python\python.exe" dsfdtpk.py aicadrv.bin -a %k
(It would be UNbelievable if python required manual environment setting.)
"%k" is the placeholder for the variable, in this case, the .bin files. "for" command uses the first "%k" to set/initialize its counter; the sentence after "do ", i.e. "python ..." is the action to execute for each input file, that will repeat along the counter.
Reinstalled python, but i tried step 5 again, and the same error keeps coming up, and I get "The system cannot find the path specified". This step is the hardest one for me... How could i set/initialize the counter; and find the action to execute for each input file. Can you help.
If you want to check for yourself, then download the folder that I've posted in the link above. You could sort the music and sounds into folders of their own while you're checking, also.
This special arcade port of Rhythm Tengoku (or Rhythm Heaven if you prefer english, as this was the first game in the series) for the Naomi sure does have some "Tempo-Up!" remixes of the Set 1 rhythm games. In fact, some of it's music is seqenced, some of it is looped, and some of it is non-looped. If only someone can make the sequenced music sound just right like in the actual game.
As of currently, many #SF formats (qsf, psf, ssf, dsf) which makes syntethyzed/sequenced music suffer of that "imperfection" due to their constructor driver not being final/ something like a stub. We would need customized sets for them (something like custom sound drivers), like in recently for some PSX rips. So, the imperfection might come from the extracted driver (aica###.bin in this case), or the #sf creation process. An update to this latter could come necessary.
I am no expert in #sf rip process, so I'm not able to answer your first question. Custom sound driver programming is no cakewalk, you know. There are sound bytes in the (gba) ROM, but I do not know its sequenced sound format for a "gsf" release/rip, if existant at all for this game. (I have read somewhere that gsf ripping is harder than psf/ssf, if available at all - so be thankful that vgm-t have the tools.)
I am not very experienced in VGM ripping myself, but I can say for sure that the sequences in the GBA version of Rhythm Tengoku are stored in MIDI. It becomes very apparent once you search for the "MThd" header in the game's ROM.
I know that the GBA version has it's own soundfont for the music and SFX, so how can i get it. I tried on VG Music Studio, but it's no use. Any tools for this?
Hello! I do not know the process of BUILDING a soundfont. Before building a soundfont file, one has to extract the sound samples, then, some other things (cannot tell more than this as I do not know soundfont format). The sound samples could be adpcm, pcm, be either pcm8 or pcm16 (rare for a gba), also they coold be signed or unsigned (no priority on that, so 'visually' discerning the bytes is exhausting!). The sure thing is, samples's starting offset could be a multiple of 0x800 (2048 bytes), or else some other number multiple of 0x100 at least. Depending on their 'signedness', the samples could have a bunch of starting '0x80' or '0xF0' or many pairs of '0xFF' bytes. You could try loading the ROM with audacity or some other DAW or sound editor, as 'RAW' and then input manually the sound parameters; afterwards get the 'time offset' (position) for each sample, and do calculations based on their sound format in order to get their offset in the binary. The SEQUENCE data, that is entirely on another league. By now you may very well have learned that any dev can create their own customized seq. format for their games.
Here is the BMS code that I wrote to extract the VFS (the GDROM link does no work) (Precise instructions, I do not remember, I do not have GDrip/VFS files anymore, so I post the code so you can extract the files yourself.) The important part is, the "ic#" files must be merged/concatenated in a certain order (not numeric as one might guess; try all the six merge combinations of those 3 (?) ic# files) before the extraction process.
Some of the extracted non-music files should be the graphic files. I do not know their format, they may be RGB/RAW, not sure.
I downloaded the (GD)ROM from the link in your first post (this thread), that now redirects to a 404 not found. Then, I examined the files in the folder, figured that files must be in the .ic# files, then I tested a combination of those three, to detect some pattern in byte offsets. When this pattern was found/figured, I merged those files and set to create the BMS code that you see on the previous post. After extracting the ROM's virtual file system, using the script created after figuring the offset patterns in the merged file, the folder containing the VFS is created, and after that, I uploaded to some file hosting, for you or anybody interested to download. I do not have any account in these filesharing services. Unfortunately, the link is no more active - I uploaded them just once and then deleted the original extracted files & ROM from my side, as those are of no use to me (to repeat, "for me"). At least, the code/instructions are present, It's just a matter to get the ROM files again for checking again, and apply these instructions to extract the VFS again.
I DID NOT have the VFS link - as I wrote, I just uploaded them once, posted the link here, and that's it - I then forget about it. I really/sincerely hope this does not offend you, judging by the tone (?) of this last post from you.
Try to do it yourself. It's not really hard with the instructions. I'm sure you won't have problem extracting the files, if you know how to use quickbms.
If this seems troublesome, you can upload the (GD)ROM files again, and I'll extract them again using the code that I posted. With the code, it's NOT hard to extract the files.
Unless, you are referring to the AICA/.dsf compiled files - yes, these would give some delay as I don't have those either, but we can compile them again with the VFS extracted files.
And please, do not take it from the wrong side - we all start from somewhere, you know.
Hehe, obviously I did not give you the "precise" instructions yet. Sorry about that.
So, let's start.
1º (Merge the IC files)
The ROM files (that contain the resource DATA) are merged in THIS order: fpr-24424.ic9 fpr-24425.ic10 fpr-24426.ic11
fpr-24423.ic8 must be some swap/temp memory of sorts. So it should not belong to "resource DATA" IC's.
To merge files, we use any hex editor. HxD has a useful "concatenate" function in "file tools" menu, for example. If there is not, then one would just copy ALL the file bytes to a new file, one by one, and paste them in order to create a new (binary) file from all the parts. Save this newly created file. Let's call this new file just "ic.bin". (Or any extension, does not matter.)
2º (Creating the bms script)
Once we have the merged IC's (filename "ic"), we can proceed with the extraction. If you look at the first bytes of the file (the starting part of any binary file is generally called "header"), you'll see the string "SimpleFlashFS", which I used to name the script for.
We create a text file, and paste the script there. Copy the lines, from ## Starts at 0x1000 to next
(The characters "#" are used as "comments", i.e. text that does no get interpreted by the program/interpreter.)
After saving the text file, we'll need to change its file extension, from .txt to .bms. An easy way if you use hex editor, is just open this text file with it, then "save as", and give a new name, with the .bms extension. Let's call this script file "simpleflash.bms". Put this file in the same folder as the "ic.bin".
3º (Extracting the VFS)
Download quickbms, and extract its contents in the same folder as the "ic.bin" file. (We just need the "quickbms.exe" executable, the others are unnecessary.)
After this, open a command window. [shift]+(right mouse click) over any area in the current folder, then "open command window". A cmd window opens. Paste there this command line:
quickbms -K -D -Y "simpleflash.bms" "ic.bin"
and press Enter key. The resulting extraction should give a "rom" folder with *.bin and *.farc files, plus one .txt file.
Here's the link for the extracted files (the "VFS"). I hope it will be of good use to you.
I do not know about the "farc" format. Maybe "File ARChive" ? But looking at the bytes, there does not seem to be any compression (at least NOT for ALL the bytes ¿?). So, some bytes could represent RAW/RGB graphics data. Try some RAW graphics reader or similar programs.
by JacintaB19 at 10:27 AM EST on November 13, 2020
Are there any programs that can read, view and extract the RAW/RGB graphics data graphics in the "File ARChive" files?
You see, there are not (on my knowledge at least) software in which you put any file and then it tells you *magically* what format it is in. In almost all of cases, one have to examine the data in a hard way. For example, if there is "unknown format" audio, but you assume it's streamed, you would use Audacity (or some other raw sound player/editor/DSP/AWS) and mess with their RAW parameters (sample rate, bit precision, endianess, etc). This very same principle you would apply, again, to "unknown format" images/pictures/graphics, but you (would have to) assume it's RGB'ed (i.e color in 3-uples or 4-uples of bytes), in which case you would use (e.g.) Irfanview (or some other raw image viewer/editor/CAD/NLE editor), and (again) mess with their RAW parameters (bit depth, RGBA order, YUV-nonYUV, yada yada - Imanot expert in graphics I tell you). I get your feelings man! When examining unknown formats, you must have enough patience, like a researcher (if it goes to that). It's not really easy - otherwise, some other users more experienced than us would have provided you the answer you expected. And I did not even start with "compression" - because simply I'm not very knowledgeable at this. If you do not get any luck with the tips I gave you (basic stuff if you ask me), then surely the unknown format in the fARC files is really custom, and nothing more to do other than reverse-engineer this format.