Hack Toast 5 for XVCD - (doesn't) Work

[paulhagstrom]

I got intrigued by this possibility and did some digging. I have not found the solution yet, but I did come up with a few things that might make the solution findable for someone else. Something I did managed to torch quite a bit of my hard drive for no reason I can figure, so I may slow down a bit on this project.

First, when modifying the Toast Quicktime extension, you need to reboot after moving it into the System Folder's Extensions folder (making testing a slow process). I guess these get loaded at startup, not on the fly.

I verified that changing the text in the Resource fork didn't work. It by itself doesn't, but there are all kinds of possible parameters to set there, so if we can solve this we might even have an MPEG-2 encoder, etc.

Although 1150000 is the standard VCD bitrate, it is stored in the MPEG stream differently. If you look at the bitstream of an MPEG file, you find a start tag (hex 01B3), then six hex digits (in three bytes) with the image dimensions (1600F0 = 352x240), a byte with a couple of other flags (aspect ratio and something else), and then 10 bits indicating the bitrate. Because it is 10 bits, it doesn't fall neatly into bytes -- you should see in a standard VCD MPEG "02CE" followed by a byte whose first digit is higher than C. This translates to 0000 0010 1100 1110 11, or $0B3B. What took me longer to figure out is that this bitrate is computed in multiples of 400, so what is stored in an MPEG file for a bit rate of 1150000 is 2875 ($0B3B). So that's the number we want to change.

Armed with this information, I thought I'd search around for instances of either 02CE or 0B3B. If I were to find $0B3B (2875) we could replace it with $1117 (4375=1750Kbits). I found 0B3B in two places, one in the resource fork and one in the data fork. I tried changing each, and I believe it was changing the one in the resource fork that caused me great hard drive pain, so I wouldn't recommend trying it again. Of course, I'm working blind here -- those could very easily have been the address of some subroutine that I patched to call out into nowhere, not necessarily initial settings for the bitrate. It does not appear that either of these worked, though.

The data fork contains a number of interesting looking things, and might be a more promising place to find the initial settings. Near the end it has something like the text we saw in the resource fork (with settings for image size, bitrate, etc.), although it isn't clear to me what those strings are -- there are a lot of "%d"s floating around, making me think that I'm looking at C string format templates, and so I don't know if there's anything worth changing there.

The data fork also contains a string reference to 1159000 which looks temptingly like 1150000, but changing it to 1759000 didn't seem to do anything.

My guess is this: This has PixelTools' encoder (API) entirely embedded in it and is using some kind of block of default values stored somewhere (try searching in the data fork for "init" and you'll come across something that refers to intializing the bitrate parameters), and there just turn out to be no calls to anything to change them from the defaults. So if we can locate these defaults (or better, if we can get it to read in the values from the VCDi resource), we might be able to make this encoder quite flexible.

BTW, PixelTools claims that their technology underlies Cleaner, which is promising from a quality standpoint, if we can tweak the parameters.

I should also say, I'm something of a novice when it comes to this kind of application hacking -- I did much better on the Apple II when nothing exceeded 64K, and I don't know that much about the innards of Mac programs. Maybe someone out there reading this does?

Anyway, I figured I'd post this update even though it didn't end in a result in case it helps someone.

[toddz]

Nice work, I have sort of placed all of my attention towards other projects but I had one final note to anyone working on this project. If you remove the VCDi resource all together (or it does not contain text), the encoder will no longer work. It is obvious that some settings come from this resource and some don't. I think what may happen is that the image size and bit rate can not be changed but some other settings can. If you look at Pixel Tools MPEG Repair Utility they have a long list of templates that sort of fit the VCDi resource. The only problem is that I have not got any of these to do anything other than give me the Toast Default or a 8k junk file.

toddz