Sound list ripper

[Asmusr]

Inspired by an idea presented by senior_falcon, I have written a Java utility to extract sound lists from TI files.

 

 

To run the program, unzip the attachment and double click the jar file (you need to have Java runtime 6+ installed).

 

 

 

Once the program is running, go to the File menu and choose 'Import Sound Lists'. Browse to a directory with TI files and select one or more files to rip. You can choose almost any type of TI file: E/A#5, ROM, GROM, DSK and even zipped files like MESS 'rpk' files. The import should only take a few seconds, and afterwards you should see a list of the imported sound lists.

 

The cool part is that you can also play the sound lists on your PC. I didn't know anything about the Java sound API before, but I managed to piece together a TMS9919 emulator from various files found on the net.

 

If you want to save some of the sound lists, tick them off and choose File > Export Assembly or Export Binary.

 

Right now this is more for fun than anything else, but perhaps I will include sound list editing in a future version?

 

Enjoy!

 

Rasmus

 

22 Oct 2014: Added the latest version with a few bug fixes (now supports editing).

 

Note 1: The tool does not have its own file format, but you can export sound lists in binary format and import (rip) them again. Just make sure that the last line of your sound list has duration 0, or it will not be recognized as a sound list by the import.

 

Note 2: While editing a sound list, if you enter numbers using the keyboard make sure to press enter before leaving a field or your changes will not be saved.

 

24 Oct 2014: New version where insert and add rows work.

 

24 Oct 2014: Version 1.2 validates sound lists before saving, to ensure they can be loaded again. Also allows repeated Insert Row and Delete Row commands.

 

25 Oct 2014: Version 1.2.1. In the table editor you no longer have to press enter to save your changes.

 

03 Nov 2014: Version 1.2.2. Sound lists were played to slowly - every row had the duration increased by one.

 

21 Nov 2014: Version 1.2.3. Imported sound lists ending in a loop caused the player to crash. Loop is now removed.

 

21 Mar 2015: Version 1.3. Added Wav File export. NOTE 28 Oct 2016: Doesn't always work, to be investigated.

 

28 Oct 2016: Version 1.4. Added support for Extended Basic CALL SOUND statements.

 

28 Oct 2016: Version 1.4.1. Bug fixes in XB support and wav file export.

SoundListRipper-1.2.3.zip

SoundListRipper-1.3.zip

SoundListRipper-1.4.zip

SoundListRipper-1.4.1.zip

Edited July 20, 2020 by Asmusr

[senior_falcon]

Very very cool! It must be nice to be multilingual, both with computers and with humans!

[sometimes99er]

Ooh, I love it.

 

I looked at your Road Hunter source and have to ask how you created the music for it ? Just an overall step by step process bullet thing.

 

[Asmusr]

Ooh, I love it.

 

I looked at your Road Hunter source and have to ask how you created the music for it ? Just an overall step by step process bullet thing.

 

 

Thank you. For Road Hunter I created the music in the MOD2PSG tracker first and then converted in manually into a sound list (a pain to do). Road Hunter is using a non-standard list format with repeats and calls, which is why it's not picked up by this utility.

 

AFAIK the standard sound list player also supports a jump command (if the first byte of a row is 0), but that's not supported by my tool yet. Problem is that the jump address is absolute, so the sound list is not relocatable, and it's not possible just by looking at the raw files to know where the jump is going.

[sometimes99er]

For Road Hunter I created the music in the MOD2PSG tracker first and then converted in manually into a sound list (a pain to do).

 

I guess many of us often see the "pain" and code a few lines to do the conversion, extraction etc. I've done some experimenting in two areas of "sounds" for the TI, namely sound-effects and music.

 

For sound-effects I did a bit of time slicing frequency analysis. Decent results from cleaner inputs. My notes unfortunately got lost after a computer meltdown.

 

For music I wanted to record live from piano/synth (using MIDI), composing something, getting it right, maybe edit, and then transfer to sound-list. It became a "pain" to try and extract from MIDI, so that one stalled.

 

Later I tried and classify different layouts for a dedicated TI sound tool as seen in this picture. I like the "matrix" and "score" layout for editing, and then "event" for easy conversion to TI. The "other" software there was called "Logic Fun" (free version but locked up a lot).

 

[Tursi]

Nice! Sounds great!

 

I tried it on Alpiner, though (the GROM), and it only found one sound list -- should it have found the others?

 

(I love how it shows the notes!)

Edited March 2, 2014 by Tursi

[Asmusr]

I tried it on Alpiner, though (the GROM), and it only found one sound list -- should it have found the others?

 

That's a difficult question. Do you have anymore information about the other sound lists?

 

I don't know much about the GROM file format. Are there headers inside the file that could break the sound lists in two?

[sometimes99er]

Concerning the Alpiner comment. Way back I extracted a few from PAC-MAN ao. Like this one ...

 

	BYTE	6,>86,>0D,>97,>AC,>1A,>B7,7
	BYTE	2,>8F,>08,2
	BYTE	2,>AB,>23,5
	BYTE	2,>86,>0D,4
	BYTE	1,>BF,3
	BYTE	2,>8E,>0B,7
	BYTE	2,>8A,>0A,1
	BYTE	3,>AC,>1A,>B7,4
...

Hope this helps in refining your extraction algorithm.

 

[Tursi]

That's a difficult question. Do you have anymore information about the other sound lists?

 

I don't know much about the GROM file format. Are there headers inside the file that could break the sound lists in two?

Well, there's the notes I posted in the other thread, which includes the addresses of two of them, otherwise I don't know anything specific about Alpiner. But since your ripper pulled a different sound list than the one I found, I was asking whether it should have detected multiple sound lists.

 

Like the ROM images, GROM files are just a raw binary dump. But your theory is possible if a sound list starts near the end of a GROM chip, since there will be 2k of padding between one chip and the next stored in the image file. Although every GROM chip can have a standard header (same one used for every cart) if it wants the OS to scan it, you can't break a sound list across chips without branching because of the 2k gaps in the address space.

 

I went back to that thread and looked... to quote myself: "Open GROM to 90A5, and we see a short sound list "04 9F BF DF FF 00""

 

0x90A5 for 6 bytes would be at offset 0x30A5 in the GROM file, and not span chips. I confirmed in the image that is the case.

 

The other one I located was the title music: " "91B9" in GROM shows a much longer soundlist starting with "03 C9 3F D4 12 01 DF 06...". " That's at 0x31B9 in the file. Scanning ahead, it ends at 0x34B8 (file offset), so it's not broken up either.

 

Attached the GROM for your debugging. (No rush, I don't require it, I'm just trying to help.) You'll find the gaps between chips at offsets 0x1800, 0x3800, 0x5800 and 0x7800, if you are curious, but that's about the only odd thing about a GROM file.

 

When I run the ripper, it only finds the list at 0x3016 (which is the level complete music).

 

ALPINERG.zip

[Asmusr]

The problem was the jumps. I'm now assuming a jump means the end of a sound list. It will now pick up the music from Alpiner and Pac-Man.

 

I have also fixed a problem with the white noise, and I'm no longer ripping sound lists with two or fewer lines.

SoundListRipper.zip

[Tursi]

Oh! So they did have jumps in them? Interesting, I didn't know TI had actually used that feature.

 

Very cool!

[+Ksarul]

I figure it is time to upload this one, as it may help decode how TI was thinking when they programmed sound lists. Here's the original documented source code for Parsec, as editable text. It may not be perfect in the GROMs, as I haven't tried to run it through a GPL Assembler (it was written for the TI version, and would require some changes to make it run in the various third-party GPL Assemblers, IIRC). The Assembly portion should assemble correctly now, according to Paul.

Parsec_Source_Code.pdf

[+retroclouds]

Just browsed the source code, impressive! We are looking at a piece of game history here.

Thank you for sharing sir!

[Asmusr]

This version of my sound list ripper supports basic editing. To edit a sound list first Import it (for now this also works as the way to Open a saved (binary) file list). Then go to the Table tab and double-click on a cell to edit it. You can also cut/copy/paste or drag'n'drop full rows. When done, make sure to Export your work as a binary file (this works as the Save option).

 

SoundListRipper.zip

 

Disclaimer: not properly tested, may damage your ears.

[RXB]

Strange way some of the GPL code is written. Clearly not the same programmers that wrote XB.

[sometimes99er]

This version of my sound list ripper supports basic editing. To edit a sound list first Import it (for now this also works as the way to Open a saved (binary) file list). Then go to the Table tab and double-click on a cell to edit it. You can also cut/copy/paste or drag'n'drop full rows. When done, make sure to Export your work as a binary file (this works as the Save option).

 

Disclaimer: not properly tested, may damage your ears.

Absolutely beautiful !

 

[sometimes99er]

Just for a bit of inspiration (not my work). It's only 2 minutes. And it gets groovy !

 

 

I'm working on a new game and, as usual, things are not progressing too fast. I'll most definitely be using RasmusM's new editing tool (post #14).

Edited March 25, 2014 by sometimes99er

[+acadiel]

I figure it is time to upload this one, as it may help decode how TI was thinking when they programmed sound lists. Here's the original documented source code for Parsec, as editable text. It may not be perfect in the GROMs, as I haven't tried to run it through a GPL Assembler (it was written for the TI version, and would require some changes to make it run in the various third-party GPL Assemblers, IIRC). The Assembly portion should assemble correctly now, according to Paul.

 

I hate to diverge and topic hijack, but does anyone have the below in disk format already?

 

Charlie Good scanned it for me, and put it up on WHTech - it's part of the original disk source of Munchman. It'd be cool to compare it to the GROM source code if anyone has it.

Munch Man disk version source code.pdf

[+OLD CS1]

I like the 'tracker look of the ripper. Gonna have to pull OctaMED back out sometime in the (near) future.

[+Ksarul]

I've got the disk versions of Munchman and TI Invaders, but IIRC, they don't have the source code on them. . .I could try and run this through my OCR software, but experience tells me it needs a LOT of cleanup when it is done. That was part of what took so long with the PARSEC code.

 

I do like this Sound Ripper though--it will come in useful if I ever get time to actually program again. . .

[+OLD CS1]

This is pretty damn handy. Any chance to get an export to wav?

[Asmusr]

This is pretty damn handy. Any chance to get an export to wav?

 

Perhaps. What's the use case?

[+OLD CS1]

Since the program generates sounds from the sound lists, being able to save a list as a wav would be a nice novelty. ModPlug and SIDplayer can do it from loaded MODs and SIDs, respectively, resulting in a sound file which can be played in a media player or otherwise manipulated.

[+OLD CS1]

I have not tried an earlier version, yet, but in 1.1 I cannot add or insert rows. Delete works fine.

[Asmusr]

I have not tried an earlier version, yet, but in 1.1 I cannot add or insert rows. Delete works fine.

 

Oh dear, that's what I was supposed to have fixed. I have attached a new version to the first post Note that you can also copy/cut/paste multiple rows.