dconvert - Raw/Compressed PCM SD Image Tool

Topics on software tools like TileStudio, comments on documentation and tutorials (or the lack of) should go here.
Post Reply
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

dconvert - Raw/Compressed PCM SD Image Tool

Post by D3thAdd3r »

Wanted to create a separate thread for feature requests and bug reports on this new tool. I don't think there are any real bugs, but not a lot of testing has been done. This tool was created for a specific need for PCM data handling, but perhaps will be more commonly used for it's capabilities to do as generic as possible data copies on any other type of raw data. It is based off what should be the last version of mconvert, and at this point the 2 code bases will divert.

It has some handy features for working with any user data including graphics output by gconvert;a feature I have always woefully done manually as in Alter Ego. These are potentially powerful but truly unspecific. The program expects a single argument which is the name of a configuration file. The configuration file specifies the format of output data among other things, and has a user defined number of entries and specific flags for converting each. The input can be either C array or binary, and the output can be either as well. It will write over only the specif parts of the file where you specify data to be converted/written, and is capable of padding a file to a specific size(will not damage other data by other programs, only padding after the end of the file if necessary). An example of usefulness, would be to use gconvert to create maps using the Meta Tile Map methoddone by L4rry for Iros, and putting just the map data into an SD image file. It can work with any file which contains C arrays and it lets you skip a number of arrays and a number of bytes from the start array before reading, so should support any need that I can conceive/wanted in the past. This is essentially the bulk of the functionality I plan as it seems to eliminate the need for manual/hex editor creation of SD card data files.

The more specialized part is for PCM, for which currently it is slated to support a weird format that is subject to change and that I do not yet have a finished demo to show off. It is not present for now. It automatically supports raw 1:1 PCM of course since that is literally byte for byte like any other data. I intend to add a few more items for PCM compression, including an interesting idea by Jubatian that might eventually make full "PCM Instrument Kits" feasible for conjunction with Streaming Music. That subject is related to this.

I am open to suggestions for other forms of specialization, as they are rather easy to add to the code base. That said, "easy", I mean to say that I have no intentions of supporting any non-raw data including any file formats that have any sort of header. Also I do not intend to add support for any data for which a transformation must happen before it is usable raw data. By this I mean something like a raw 16bit PCM needing to be converted to 8 bit before a compression can happen; I want to keep the code base dead simple, and there are so many other tools with all the bells and whistles to get raw data better. I do not mean to go into graphics specifics on this, as those things should be added directly to gconvert. Types of specialization I would consider adding would be something akin to taking a number of values, and compressing them into 4 x 2 bit numbers in a byte, RLE, or something that helps format simple/generic user data. If someone has a specific need for a game in development then it would be much higher priority than just "nice to have someday" stuff of course.

Think that is it....(and I feel guilty to do this, honestly)...the tutorial will be finished on the wiki eventually. For now the placeholder is here which might be enough to get started. This will combine, to complete the PCM SD image resource additions for the SPI Ram Music demo(which I previously did manually...which is not clean), which will be called done(serving it's purpose of showing streaming music and multiplexing the SPI Ram). More specifically PCM stuff will be a separate demo as it is just to far an offshoot to directly call it a Streaming Music subject, and probably be tied in with this quite closely.

This is up on the streaming-music github branch I need to reconcile all that with the current kernel happenings...TODO. FYI, the only thing different about the streaming-music branch is uzebox.h, defines.h, uzeboxSoundEngine.c, mconvert, dconvert, SPIRamMusicDemo, and of course adding those to the makefile so they build. I needed the latest so I literally pulled that, threw those things over the top, and there we go works with all the new kernel additions from Jubatian. I am just too nervous at the moment to do it the right way, as I don't want to mess something up on github(TODO learn basic github usage :roll: )
Post Reply