if that's the case, then the ssa is separate. It's not being contained within the video file itself, it's being packaged separately.

DirectVobSub is really frigging smart, you see. So if you take a .ssa file that's got the same name as your video file (except with .ssa instead of .avi or .ogm at the end), and you stick em' in the same directory, it'll play.

For a fun experiment, rename one of the .ssa's to some hardsubbed video file (say a read or die ep, or some movie, or whatever you've got lying around that's a .avi). Stick it in the same directory as that file, and play that file. Directvobsub will render the subs there, even though the video stream isn't the one it's supposed to go with.

OGM makes that stuff internal, through a process we call "muxing" -- it makes the subtitles into a stream in the file, rather than a separate file. This is nifty, and keeps things cleaner than having two files lying around. But it doesn't support .ssa, so I think groups like ahq are probably stuck with the choice: find a way to convert ssa to srt (this isn't particularly difficult, but you lose a degree of control over the subtitles this way), stop working with .ssa entirely (good solution if you're ripping the subs and not retiming them or doing anything too fancy), go to a different container like mkv, or give you two files for the price of one with a separate script.

Seems like they're picking the last option, from what you're saying. I'd personally probably avoid that, since it seems like kind of a waste of the potential of the ogm container. But that's just my opinion.