Decoding Cue Points in CriWare USM Containers.

[L33THAK0R]

Pre-preface

I originally wrote this guide back in June of 2021 for myself (I got a bit of a shit memory alas) and another hobbyist that I usually release my research to, so if anything is outdated I do apologise, I'll update it accordingly. I doubt this will be of use to many since I don't see many folk utilising lossy (in my case lossy to the point where the difference between lossless/lossy offerings aren't visibly perceivable to the end-user), but in the off-chance it does, attached is an archive containing all the cue-points to "Batman: Arkham City", since this title benefits the most from re-coded USMs since the video stream contains a duplicate video stream (3840x1080) that is unused in-game.

Preface

This process is going to heavily rely on using HxD (Hexadecimal examining/editing tool) and is a bit finicky and MAY vary on a title by title basis. In this guide we’ll be using a cinematic “.usm” from the title “Batman: Arkham Origins”, as the “Arkham” series (Post “Batman: Arkham Asylum”, which uses Bink1 (.bik) videos for cutscenes), have a very easy to understand, and universal naming system for cue points and their respective triggers (commands such as controller rumble and termination of video rendering), that are used in their respective cinematic “.usms”.

I say cinematic as some “.usm” files contain short or low-res videos used for purposes such as “training videos” that show the end-user new moves or attacks and how to execute them. I haven’t got around to decoding the naming scheme for these cue points/triggers, but with a bit of testing it shouldn’t prove to be too tricky (hopefully).

The reason why Cue points NEED to be included if present in the source file, is that failure to do so will result in the title hard-locking at the point of video-render termination, as well as features such as controller rumble during cutscenes being absent.

A final reminder: not all “usm” files have cue points, even a title which has a “usm” with cue points may not have such present in other sibling “usm” files, so be sure to always check!

Part I: Finding the cue points/triggers and ordering them.

a) Firstly open up your “.usm” of choice and search for the decoded text phrase “CUEPOINT_INFO”.

43 55 45 50 4F 49 4E 54 5F 49 4E 46 4F

b) Select all decoded text past the offsets with the decoded text string of “name.time.cue_type.parameter”, as seen here in the below image (See Figure 1).

Figure 1


c1) Now we give each trigger it’s own line and tidy it up in a tool such as Visual Studio Code as seen in the below image (See Figure 2).

Figure 2


c2) For those of you wondering where the

,1,

came from, after sifting through documentation the general* structure for a cue point is as follows:

TIMESTAMP,1(TRUE)/0(FALSE),COMMAND

*newer USM containers may have slightly modified structures, but this is very uncommon in the cases I've seen.

Part II: Decoding the time stamps for the cue-points/triggers

a) The time stamps used by a given cue-point/trigger will ALWAYS be in milliseconds (ms), so a 2 minute time stamp will be stored as 120.000ms.

b) To determine the timestamps go back the your hexadecimal editor of choice (HxD in this guide) and go to the offset before the first offset we mentioned (decoded text “CUEPOINT_INFO”) with the decoded text “<NULL>”.

c) Now go to the hexadecimal viewer and start working backwards, you’re looking for a group of hexadecimal entries that correspond with your last trigger. In this case “Trigger=End” will have a timestamp near the end of the video file.

d) The following screenshot (See Figure 3) indicates the pair that we are looking for is “02 5A DD”, which as you know would be 154333, when converted to decimal. This lines up with our video which is approx. 155 seconds long!

Figure 3


e) Now continue working backwards, until you have all the relevant pairs (the following figure will have the relevant pairs highlighted, see Figure 4)

Figure 4


f) Now we can paste these translated pairs into our document and we have a complete cue points file! The following image displays the complete cue points file (See Figure 5).

Figure 5


g1) There is some slight additional formatting to do to our cue point file before we're done, the following image (see Figure 6) displays this additional text, which will be explained momentarily. These values are part of the core USM cue point syntax and never change, at least not in the cases I've observed.

Figure 6


g2) "1000" simply indicates how many milliseconds is in a given "tick", I've never seen this be anything other than 1000ms (1 second), someone else may be so inclined to figure out where this value is stored, but when I wrote this guide I didn't investigate this anomaly.

g3) "0,0,start" is used to determine at what point to begin playback of the container, as for why there is a false flag I honestly either forgot or didn't find out but regardless I didn't document this, I've never had issues with keeping this as a false value.

g4) "start" simply gives the command to begin executing the cue point commands that follow.

If I missed, forgot to include anything or anyone has any followup questions please let me know.

[TheDarkSid3r]

THANK YOU!!!
I have been trying to find a way to get cue point timings out of USM videos for years at this point and I am so glad that someone has posted a comprehensive tutorial such as this one (let alone a tutorial at all)

[L33THAK0R]

Originally Posted by TheDarkSid3r

THANK YOU!!!
I have been trying to find a way to get cue point timings out of USM videos for years at this point and I am so glad that someone has posted a comprehensive tutorial such as this one (let alone a tutorial at all)

No worries, I'm honestly surprised anyone found this useful but glad its been of use, gives me pause to whether some of my other research might be useful if made public.

[TheDarkSid3r]

hmm yea, perhaps other things could be useful to at least SOMEONE
anyways here's what i was able to get thanks to this post

[L33THAK0R]

What title is that from? Can't say I've ever seen that many triggers before for a single file.

[TheDarkSid3r]

sorry i'm this slow to respond haha
each line (aside from that "RoundBreak" section) is actually a different video file, each with a single "transition" cue point
these are from the 2011 title of the series You Don't Know Jack, most of them question bumpers
the "transition" cue point is used to tell the game when Cookie should begin his next voice line -- essentially the point at which the video starts transitioning/moving into the background
so game action is happening before the main video ends and the background loop begins (as it leads into the background loop)

[L33THAK0R]

Originally Posted by TheDarkSid3r

sorry i'm this slow to respond haha
each line (aside from that "RoundBreak" section) is actually a different video file, each with a single "transition" cue point
these are from the 2011 title of the series You Don't Know Jack, most of them question bumpers
the "transition" cue point is used to tell the game when Cookie should begin his next voice line -- essentially the point at which the video starts transitioning/moving into the background
so game action is happening before the main video ends and the background loop begins (as it leads into the background loop)

No worries habib, dont stress about lengthy response times. That's very interesting to hear, I'll definitely have to keep this in mind should I repack these titles in the future.