</div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (complich8 @ Jan 29 2004, 08:24 AM)</td></tr><tr><td id='QUOTE'> if that&#39;s the case, then the ssa is separate. It&#39;s not being contained within the video file itself, it&#39;s being packaged separately.

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

For a fun experiment, rename one of the .ssa&#39;s to some hardsubbed video file (say a read or die ep, or some movie, or whatever you&#39;ve got lying around that&#39;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&#39;t the one it&#39;s supposed to go with.

OGM makes that stuff internal, through a process we call &quot;muxing&quot; -- 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&#39;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&#39;t particularly difficult, but you lose a degree of control over the subtitles this way), stop working with .ssa entirely (good solution if you&#39;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&#39;re picking the last option, from what you&#39;re saying. I&#39;d personally probably avoid that, since it seems like kind of a waste of the potential of the ogm container. But that&#39;s just my opinion. </td></tr></table><div class='postcolor'>
Jup jup all true complich8... and it is a waste to put in an extra file if you can just mux it in with the ogm. And ssa is easily converted to srt.