Ok, well even though the latest version is alpha (meaning I've only tested it), I've decided to put the link up for v_12.

Mentioning this first (since it's important): Do Not attempt to update either a retail or earlier fan_based tpa file with this program (use tpaAdd is this is your intent). The reader exports new .tpa files (name it whatever you like), and these are the .tpa files you must use if you plan on using this program to add a .cau file (these are basically wbor data blocks which are either exported out of other tpas or created by converting a pcm or ima adpcm wav into a .cau file).

Reason (for anyone curious): The last table entry of retails is slightly smaller (24, as opposed to 36 bytes), and I've made no allowances for this (and don't plan to).

OK, I'm not sure what you mean. Is it that the distance from the last "WBOR" text string in the ID Table to the first "WBOR" in the Sample Table is 0x24 bytes (decimal 36) instead of 0x38 bytes (decimal 56) like between "WBOR" strings inside the ID Table? That's because the ID Table entries don't start at the "WBOR" string, but 20 bytes earlier... while Sample Table entries start with the "WBOR" string.

Quote:

The blank.tpa files we've been using for years have an erroneous entry count and some extraneous data written past the last table entry and I've made no allowances for this either (and don't plan to).

Onto the .caus. Dealing with wav data as .cau files is preferable for several reasons. The wav data can be either .pcm or compressed (ima adpcm), you can import the wav data as a cau file from other tpas along with the caption data, and it also gives us the ability to add our own caption data to a converted wav (wav into .cau) which can be imported into the new tpa files.

I have to stress that this has been barely tested, by me only. Near as I can tell though, everything seems to be aok with the imported sounds, along with tres displaying the caption data. I'll give the additional instructions below (although they are also included within the read_me file), after mentioning that Machf's & Big Red's input has been quite helpful with this little project and I have Machf to thank for the CRC32 code (I found it nerve-wracking, personally).

I wonder why...

Quote:

ADDITIONAL CONTROLS:

Export as .cau: This is a radio button. If checked, wav data exports as a .cau file (single or mass export).

CONVERT BUTTON: This control converts a wav file (pcm or dvi/ima adpcm) into a .cau file for later import. If adding caption data to a wav, you must enter the caption line(s) into the fields before clicking this control.

EXP_TPA BUTTON: This control creates a user_named tpa file which this program requires.

ADD_CAU: This control imports a .cau file into a .tpa file. To use, select .tpa (not a retail, and not a fan_based (blank) tpa file), enter a 'SOUND ID*' or string name for your entry, then click the 'ADD CAU BUTTON'. Updating may take several seconds or a few dozen, depending on the size of the data being written and the current size of the target .tpa. Allow the program to finish before doing anything further (check caption data readbox for program's current status). A log file is also generated after an import (and appended to if earlier imports occurred) to eliminate the potential of forgetting what name one might have assigned to a particular sound.

Accessing these .tpas: These are basically assumed to be used by atx (Maps/LVL/Example Tpas) and need to be placedinto the aforementioned, bracketed location. Be certain that you either create, or edit the existing .ini level file to be able to access sounds from the .tpa (else, atx won't know where to look for them). Of course, if you're working on a stand alone package, they can also be used as the main .tpa within the data folder.

Extent of testing: Created several .tpas and added up to 24 entries, including larger music waves. All clips played within trespasser, all caption data (including custom caption data) displayed -

That's about it. If one or two people could check it out, that'd be great.

I'll try it. But tomorrow, I guess, as it's already late.From what I can tell right now, it still won't allow you to specify the Attenuation Factor or the Master Volume for a sample, the same way as TPAadd... you just need to be able to store those as 4-byte floats.And it would be great if just line breaks were used to separate caption lines when typing them in a single text area instead of separate textboxes.

OK, I'm not sure what you mean. Is it that the distance from the last "WBOR" text string in the ID Table to the first "WBOR" in the Sample Table is 0x24 bytes (decimal 36) instead of 0x38 bytes (decimal 56) like between "WBOR" strings inside the ID Table? That's because the ID Table entries don't start at the "WBOR" string, but 20 bytes earlier... while Sample Table entries start with the "WBOR" string.

Righto. In the retails, the data stopped at 24x while tpaAdd added 0x0 to compliment a full 0x38 even though those bytes aren' t used or read (unless of course, a new entry is made). The nice thing about that is that every offset is +0.x38 (or 56 dec.) longer when adding an entry, so there's no need to read the last table entry to determine whether it's 0x24 or 0x38. I'm not saying you can't determine this difference, I just don't see the point in doing so. In my opinion, we shouldn't be adding entries into the retails anyways; better to keep them pristine and original and they're rather large to begin with.

Quote:

IFrom what I can tell right now, it still won't allow you to specify the Attenuation Factor or the Master Volume for a sample, the same way as TPAadd... you just need to be able to store those as 4-byte floats.

No, hadn't even thought about it. To tell you the truth, I haven't even looked at an exported .cau to see if that information is held in the wbor sample block or it only exists in its table entry. Obviously, the program lacks alot of features too since it wasn't intended to be an audio editor. As is, it's a caption reader with a few extras -

Quote:

And it would be great if just line breaks were used to separate caption lines when typing them in a single text area instead of separate textboxes.

That could probably be changed, it was just the way I thought it up originally since I'm not certain whether trespasser wraps a caption sentence (if too long), or would simply truncate it. The separator within the caption data doesn't appear to be a valid line break either, but rather another millisecond entry (how long to display the next sentence). I could be wrong on that assumption, but that's what it seems to be. There's also a difference between the beta and retail with regards to the caption data. The retails have a terminating 5byte entry (value seems nonsensical to me, so I insert a benign, pointless string), while the beta's caption data ends immediately upon sentence end.

@Edit: Attachment has version with efts_option. Haven't the time to test it in-game, off to work -

Here's a blank .tpa I made for testing. Your app (previous version, just downloaded the last one now) doesn't appear to add the .cau files properly to it (tested it with the Menu.tpa file, extracted al entries as .cau files and tried adding them to the blank.tpa to get a duplicate of the original Menu.tpa file)... could I look at your source code?

Your app (previous version, just downloaded the last one now) doesn't appear to add the .cau files properly to it

No, it wouldn't. The program is looking for a tpa file with its 0 entry already present, not a file with just a header as was the case with tpaAdd. That's why I expressed the need to use the program's generated tpas (along with the other reasons mentioned earlier). Onward;

The program expects a .tpa file with this valid entry, mainly the ones exported from the program has a 'missing' wav as its zero entry. So, file pointer goes to 0x1c, which would be the 1st (0) and only offset, reads that offset, adds +56 and then deals with the new wbor entry. Technically, the program should have crashed since the 1st seek for the file pointer goes past the eof of the heaader.tpa file you sent. If you want to rebuild the Menu.tpa, just create a new .tpa file with the program. You'd just skip importing the 00_cau, since that's already taken care of (missing).

The Source: I won't release it publicly since it's in cobbled together stage (and I'm not done with it), but I'll send you the source 'as is'( I don't know if you'll be able to follow it though since it's basically 1 function placed after another, along with numerous if statements and control ints (some used globally)). Honestly, I don't want to change the way it works either, that's why I set it up to use the .tpas the program itself exports. There's little difference between creating a tpa with 1 valid entry or just a header to start, but that isn't the way I I laid it out. I don't see any need to change that. You need to start out with a good .tpa file; the program already provides that.

*I still need you (and someone else would be nice, too) you to test it as requested, though. With the reader's .tpa files and adding .caus to it, verifying caption and wav play in-game.

Machf, the version in the attachment will work with your blank.header tpa files now, just not Andres old blanks. So yeah, you can use your version of a blank, or the version the program produces. Either or -

Hmmm... I also made another .tpa file with just the MISSING entry from the Menu.tpa in order to add the rest... the end result is exactly the smae size as the original Menu.tpa, but data becomes somewhat garbled as you add more .cau files, apparently. The last added .cau is aligned matching the original, but earlier ones have had their data displaced (the next-to-last one has the smallest displacement, the very first one has the largest, apparently 156 zeroes before the actual start of the original data, which means another 156 bytes at the end have been lost in that entry). Also, the value for the offset to the Foley Table hasn't been updated in the process (it should point right past the last .cau always), and as previously mentioned, other differences are that the Attenuation and Volume values can't be entered for each .cau being added (something TPAadd can't do either but is much needed).

Are you using the latest version of the File Formats document for reference?

I didn't even get into the foley table, machf (and isn't that just for the effects.tpa?). I hadn't planned on this being used on the retails at all, just new tpas. Since it doesn't take the table into account, the .cau block is going to be added after the table, and that of course wouldn't work.

Quote:

Hmmm... I also made another .tpa file with just the MISSING entry from the Menu.tpa in order to add the rest... the end result is exactly the smae size as the original Menu.tpa, but data becomes somewhat garbled as you add more .cau files, apparently

I don't see how. I built a .tpa file with over 70 entries now and they all play perfectly, and that includes music clips in the megabytes.

Quote:

ther differences are that the Attenuation and Volume values can't be entered for each .cau being added (something TPAadd can't do either but is much needed).

Well, those values are fairly generic, 192, 36 respectively. There's little point in giving the average user the ability to enter those values, hence the defaults are put into place if you check the option for 'import as Eft (effect).

*Machf, your 1st blank.tpa worked perfectly, as did the reader's tpa for restocking a new menu.tpa. If you use either of those, everything seems just fine -

Machf, the version in the attachment will work with your blank.header tpa files now, just not Andres old blanks. So yeah, you can use your version of a blank, or the version the program produces. Either or -

Well, I've used that version to just add the MISSING .cau and compared it to the MISSING.tpa file I made myself - and they don't match. Never mind the Foley Table offset and the Attenuation and Volume values, you've inserted 20 zero bytes at the end of the first (and only) ID Table entry, so the file is 20 bytes longer... as I said, ID Table entries *don't* start at the "WBOR" string, they start with a 20-byte header before it. That's why I don't see what you mean about the last entry not being the same size as the previous ones - they are *all* the same size, it's just that you aren't looking at the right place.

Rebel wrote:

I didn't even get into the foley table, machf (and isn't that just for the effects.tpa?). I hadn't planned on this being used on the retails at all, just new tpas. Since it doesn't take the table into account, the .cau block is going to be added after the table, and that of course wouldn't work.

Even if the Foley Table isn't present, the offset entry in the header always is - it points at the location the Foley Table *would* be - the end of the other data. So, for other .tpa files it just matches the file length.

Quote:

Quote:

Hmmm... I also made another .tpa file with just the MISSING entry from the Menu.tpa in order to add the rest... the end result is exactly the smae size as the original Menu.tpa, but data becomes somewhat garbled as you add more .cau files, apparently

I don't see how. I built a .tpa file with over 70 entries now and they all play perfectly, and that includes music clips in the megabytes.

But I'm looking at the actual structure, as I said. Those unnecessary zeroes I just mentioned are the ones which cause the garbling...

Well, I've used that version to just add the MISSING .cau and compared it to the MISSING.tpa file I made myself - and they don't match. Never mind the Foley Table offset and the Attenuation and Volume values, you've inserted 20 zero bytes at the end of the first (and only) ID Table entry, so the file is 20 bytes

I know it's twenty bytes longer, and it's account for in the offset. If you rebuild a menu tpa file, export those as cau files, then compare them to the cau files extracted from the original menu.tpa, you'd see they're a perfect match. There's no garbling of data, it doesn't matter if the overall file size is 20 bytes longer, it doesn't matter where the file offsets start, so long as the file offset points to the correct start of the wbor block, and this program does that. They play, and they play correctly. There is no garbling of data. .. those extra zeros mean nothing, just like that message inside of Andres' blank tpa files, it's not read, it's ignored as if it doesn't exist.

Quote:

ID Table entries *don't* start at the "WBOR" string, they start with a 20-byte header before it.

Sure, I'm aware of that, and where all the data goes. How the hell else would I be able to update the tpa if I didn't? The xtra 20 bytes as you're calling them aren't written to with valid data or read unless a new entry is made. Truly, this has no bearing on tpa validity at all. I know you're a perfectionist Machf, but there's absolutely no reason to protest the presence of 20 zeroed bytes.

ther differences are that the Attenuation and Volume values can't be entered for each .cau being added (something TPAadd can't do either but is much needed).

Well, those values are fairly generic, 192, 36 respectively. There's little point in giving the average user the ability to enter those values, hence the defaults are put into place if you check the option for 'import as Eft (effect).

Huh? No, they are floating-point values, the attenuation factor is needed for such things as dinosaur vocals so that they sound louder the closer they are and stiller the further they are, typical values being about 1.5. As for the volume value, it's typically used with negative values (down to about -30, I believe) for samples that have a too high volume from the original source they were taken from. Other entries just set them to 0.0. Haven't used that option you mention, I was wondering what it was supposed to do. Instead I'd suggest you having two textboxes for the Attenuation and Volume with pre-entered values of 0.0 in both. Or maybe a couple of sliders by default positioned at the 0.0 end...

Quote:

*Machf, your 1st blank.tpa worked perfectly, as did the reader's tpa for restocking a new menu.tpa. If you use either of those, everything seems just fine -

Huh? No, they are floating-point values, the attenuation factor is needed for such things as dinosaur vocals so that they sound louder the closer they are and stiller the further they are, typical values being about 1.5. As for the volume value, it's typically used with negative values (down to about -30, I believe) for samples that have a too high volume from the original source they were taken from. Other entries just set them to 0.0. Haven't used that option you mention, I was wondering what it was supposed to do. Instead I'd suggest you having two textboxes for the Attenuation and Volume with pre-entered values of 0.0 in both. Or maybe a couple of sliders by default positioned at the 0.0 end...

Well, I just copied the most commonly used values for the dinosaur vocals there. Sure, you could have textboxes for this, but I'm still left wondering how many will actually know what to do with them. I did add what you suggested, but I was trying to keep things simple.

*Data point: I'm actually writing one incorrect value at 0x10. I assumed this value to be the total size of the wbor table blocks (and perhaps +20 too), but it's actually supposed to be the overall file size of the tpa file.

*Data point: I'm actually writing one incorrect value at 0x10. I assumed this value to be the total size of the wbor table blocks (and perhaps +20 too), but it's actually supposed to be the overall file size of the tpa file.

Well, that's the one I was refering to, it's the Foley Table offset. For no Foley Table present, it's the same as the file size.

Anyway... I'm attaching two rebuilt Menu.tpa files using your machf_ver executable. Menu4.tpa was built using my Blank.tpa and Menu5.tpa was built using my MISSING.tpa. Except for the 20 zeroes, the Foley offset and the Volume and Attenuation, Menu4.tpa matches the original. But Menu5.tpa is another story altogether... take a look at it. Open it with your app... ifyou dare.

Well, I'll take a look at it, but the program works with your blank.tpa and the reader's generated .tpa. We both knew your missing.tpa file was screwed from the start, so I'm not certain why you even tried building that one.

Quote:

Except for the 20 zeroes, the Foley offset and the Volume and Attenuation, Menu4.tpa matches the original.

Okeedok. So, we can ignore the zeroes since their presence is meaningless & benign, the Foley offset, which except for the Effects.tpa is nothing more than total file size, so that's correct as of now, and volume and attenuation values can be attached to the .cau before import. Of course, they might not be precisely the same as in the original Menu Settings, but I imagine the general values used would suffice to duplicate those original values. I'm pretty much satisfied. You probably aren't, but i am.

Considering the usable tpas;

If the preference is to have a completely empty .tpa file (no stock missing wav), I'd say use your blank.tpa file in lieu of one the reader generates. Technically, It isn't really required for atx accessed .tpas anyways as if a sound is missing, the engine isn't going to look for the missing wav there anyways (it'd be looking for it in one of the retails). I'd say eliminate my version altogether, but if you're going to use it as the replacement stream.tpa in a stand-alone for example, it really should have that missing wav as its 1st entry -

Quote:

Well, that's the one I was refering to, it's the Foley Table offset. For no Foley Table present, it's the same as the file size.

Yeah, initially I wasn't certain what the value held (or for what). I've since fixed it. I put up ver_14 on the temp page & included one of your good blank tpas in the zip. That includes the option (just radio button to include stock values) for importing a dino sound or any other sound that might use or need those attenuation values.

*Menu5: (used a hex editor to check it out). Yeah, the data_offsets are wrong for one, but that isn't the program's fault. You didn't use an approved .tpa file.

* If anyone does use this program, if they use either your blank or the reader's .tpa, everything will be fine. The only other thing I'd recommend is that if it's your intention to add a sound, don't be sound_browsing through the .tpa beforehand. Just load up the .tpa file to add the sound (.cau file). If you wish to review it, do so afterwards. ..

Hmm. You know, the rapid Q code would look quite similar to what a stringstream could replicate. So yeah, that looks possible, I'm assuming you mean do this in lieu of having a temp_wav file, right? Windows PlaySound () has the same similar functions, and it can play buffered data instead of a file, except that it does have that inherent MS bug (not addressed or fixed until Windows7 release) that if the buffer is over 3mbs (I think that was the threshold listed) it causes a runtime error. Other than that, most clips could be played from memory.

*No, I was using your updated format page, but I also have a copy of the older version on my harddrive, and I would periodically use that instead of referencing the updated version, so I imagine from time to time I might have looked at information not quite right.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum