some bitmap changes, sound cue points

[MrBrax]

make some ghetto fix to properly extract bitmaps with different encodings and whatnot, and found out that cupt = cue point files, extract that into json metadata because wav doesn't natively support it, and writing data to aiff doesn't seem to work all that well

[Brian151]

I have not forgotten of this project...

I am a bit low on time right now, so I'll review this later.

JSON will be used extensively, I can promise you that.

Would you be interested/able in dealing with the .swa format? It's 'sorta' MP3, but it has extra data, like cue points. I'd prefer splitting such data out of the files.

[tomysshadow]

SWA is easy. You just check if it says "MACR" a few bytes in. If it does, the first int in the file is the address of the MP3 data. Otherwise it's literally just an MP3 file with a SWA extension. Unlike most sounds, SWA files are zlib compressed in DCR files, presumably because they are technically Xtra Media, not natively supported sounds. I still don't know how to get at cue points for them though, as I haven't taken a good look at the headers.

I'm still looking into how Shockwave works, I just haven't been coding much. This has become less of a priority right now to my other work.

[Brian151]

@tomysshadow Github needs a facepalm Emoji... Like I said "sorta" MP3... I was never able to figure-out where the actual MP3 begins, however Might document that somewhere

To be fully honest, I've been doing other things, also

@MrBrax I'll extend that delay, stuff happened today... It's now midnight, close to my bedtime, and people are shooting fireworks off, rather not have something happen while I'm looking at code or making comments.

[MrBrax]

Weird file format though, i don't think i've ever heard of it before. Is it really such a good idea to continue using it?

[tomysshadow]

SWA is ShockWave Audio, a format Shockwave uses for compressed audio. We'll need to be able to support it if we want to extract all audio from Shockwave.

[MrBrax]

@tomysshadow ooh i see now, i misread the first reply as to use swa for all exported audio

but again, i've never seen the format and it doesn't appear to be in any of the files i've been experimenting with so i can't do much

[Brian151]

Welp...

Firstly, SWA is almost certainly to be found in DCR, and also any DIR from dir-opening a DCR. Spybotics: The Nightfall Incident uses SWA As aforementioned, aside from some extra data, it's MP3, and most players will play it normally. But, that extra data could be important in some games/animations, thus cannot be over-looked. I also have had issues editing/playing SWA in Audacity, so the extra data might be causing some problems...

On lists: no Case-sensitivity? ... GREAT

yeah...cuz... 'symbols' ... [#GAMESTATE:#pause] From what I understand, using them as strings prefixed by # will work No idea how this stuff is done in the original player/API...

Yes, a JSON parser could probably be used. In effect, my list parser does exactly that. With a few changes, it'd work as a JSON parser. I don't see the merit for changing stuff, though...

In general, parsers range in difficulty to implement. Many elements of this project are parsers... The main thing is that you have to understand the format you're trying to parse... For example, DIR... First major thing is that it's based on RIFF/RIFX, so, what characteristics define those formats? ("RIFF/RIFX are container formats comprised of named sections") Now, how do all these sections relate to one another? Finally, what are the various formats of each section, and even, sub-formats. Are there embedded files? ("yes, SWA,Flash SWF, W3D, image files, etc...") How do we open them? ("images we just extract and maybe embed, SWF and W3D need players/viewers.") That's the concept, but there are many cases that a format is very hard to parse. People who rip assets from video games know this, and there are some games they won't touch due to just how annoying the file formats are. Want some pointers (sadly, no/few comments in my code) , take a look at these: https://github.com/Brian151/INI.js This one was fairly straightforward https://github.com/Brian151/spongebobzelda/tree/master/utils/Map_Converter Note I have a total of four scripts handling the maps. One goes from XML to JSON, and the others incrementally make it a much more coherent format. https://github.com/Brian151/Various-Projects/tree/master/Flash/fla_buster If you don't entirely understand a format, ask around or google it. A lot of my knowledge concerning this project is second-hand. That textwall in mind, good luck!

Bitmap SpecificData: awesome! If you're willing/able, maybe you could look at the SpecificData for all CASt types?

I think that's everything I have to say... I'm still a bit busy to give this a thorough review atm...

[MrBrax]

Scrapping my "previous" message as I'm 100% sure now.

These two are examples of fields/strings being used at runtime by the game:

[#partId: 3, #master: 2, #MorphsTo: 0, #description: "", #junkView: "", #UseView: "20b003v2", #UseView2: "", #offset: [220, -15], #Properties: [#Weight: 2, #speed: 2, #FuelConsumption: 1, #Strength: 1, #EngineType: 4], #Requires: [#a16], #Covers: [#a16], #new: 0]

[#partId: 182, #master: 181, #MorphsTo: 0, #description: "", #junkView: "", #UseView: "20b182v2", #UseView2: "", #offset: [0, 0], #Properties: [#Weight: 3, #Speed: 3, #Fuelconsumption: 3, #Strength: 3, #Enginetype: 5], #Requires: [#a6], #Covers: [#a6], #new: 0]

Note the FuelConsumption attribute in Properties.

And i just tested it just to make sure:

What i nice language...

Anyway - bitmaps, sounds and fields are already being parsed by the python script, and with the game i'm using i haven't really found any other interesting types.

[Brian151]

So, just gotta resolve case-insensitivity

You read those in reverse, I think, AND Schockabsorber documents Lnam ("manL") already. Script Name Table. I should merge the information into the format notes, yes... The other is something to do with the movie's animation frames/score... There's four such sections, and all of them aren't sufficiently documented, at least, I can't read said docu...

Can you remove both of those new entries? Or Lnam, for certain? I know how it works, I just need to put that in my own notes...

[MrBrax]

sheesh, didn't know it had documentation.. there goes like 5 hours of byte traversing :/

[tomysshadow]

Everything beginning with VW is to do with the timeline. VWSC is for the score and VWLB is for the labels. Haven't taken a look at precisely how they work though. Not to be confused with SCVW, which begins with SC, not VW, and is for film loops.

[Brian151]

@MrBrax I never added script-related sections because documentation on them is kinda horrid/incomplete, excluding Lnam... sry...

@tomysshadow alright Schockabsorber's documentation only hints at how they work, it's not really specific enough to the details, from my observations. Film loops will be fun... let's hope the sections are at least similar to those defining the score of the main movie...

[Brian151]

Other than the Lnam issue, nothing here seems like it causes a problem...

I wonder if I should get Python set-up soon... I haven't touched that language/interpreter in so long... Simple fact is, I can't thoroughly review anything made with Python right now...

merging...

[MrBrax]

well it's your repo, you probably could've removed it, i don't know much about git at all haha

i'm gonna have to rework the python thing though, when i started i didn't know dir/dxr could have multiple cast libraries, so now when i found one that had multiple, it overwrites the previous ones