The flags look fine.
The problem is unlocking a track; when you do that, state information gets invalidated and recreated the next time you lock the track again. The only state a host program would be interested in is the current random seed associated with the track, since you don't want to read the same data twice from weak bits normally
Locking a track can be expensive btw., which is mostly only noticeable if your PC is not very fast, and you try a game that stream audio/video from disk; then you'll notice. The only games I can think of on ST are the ReadySoft games, such as Dragon's Lair.
However, if you still want to lock/unlock a track, then there is a solution: you should query the current random seed used and restore it.
Here is how:
Each track has an individual random seed.
Each time you lock a track use CapsTrackInfoT2. Save the wseed variable returned. Do not change it (as it may weaken the simple random generator).
Next time you lock the same track specify DI_LOCK_SETWSEED and set wseed in the structure to the previously obtained value.
The first time you ever lock a track wseed is always reset; you can observe this by checking the value returned.
Therefore, you should lock the track twice
instead of once with your approach.
The first lock will decode and initialize the track with normal flags, the second time you should specify DI_LOCK_SETWSEED to continue the track randomization from the state where it was before you unlocked it. You should save the returned wseed after this call as well, since that is the updated state.
If you do this correctly wseed values before your call and after the call are different for any track that has weak bits.
It is much simpler with a preloaded image; all of the track are already locked, so you'd lock the track only once.