Josh Coalson Wrote: > > AC3 is compressed and there is no direct correlation > between time and the FLAC 'sample number', in fact, the > FLAC 'sample number' only corresponds to an arbitrary > position in the AC3 stream. the only reason AC3 can > be fed to FLAC at all is because it is packaged in a > WAV file to look like PCM samples, but it is really > just chopped up compressed data. this is also why the > FLAC compression ratio on it is so bad. > > if the WAV'ed AC3 stream is constant bitrate you can > form an estimate of time to 'sample number'. if the > padding is inserted non-uniformly then the estimate > will be choppy. if the bitrate is not constant, all > you can really assume is that a higher sample number > corresponds to a later time. If the conversion utility is run with the *--verbose* option (somewhere before the input file name) then some debug data will give the AC3 frame size in bytes (eg "AC3 length: 14162397; frame length: 1792"). The conversion will pack each AC3 frame encountered into an IEC61937 frame of 6144 bytes; there's a one-to-one correlation between input and output frames. So if you (Andy) know which AC3 frame you want to cut on, you can work it out.
(Note that each output frame in a converted DTS stream is padded to only 2048 bytes. I must confess that I couldn't find enough documentation to justify this; it was just the value that worked. I welcome any explanations or suggestions for improving that aspect!) Even if the AC3 file isn't of a constant bitrate, that frame correlation will hold true -- so if you're starting from an AC3 frame number you should be able to go on from there. Beware that the verbose output will only tell you the size of the first AC3 frame (just enough data to make a guess at the size of the padded output file so the WAV header can be written) so you can't use it to determine if the bitrate changes per frame. Josh Coalson Wrote: > > once you get an estimate of the target sample for a > given time, the AC3 decoder make take some time to > sync the stream again.Because of the one-to-one frame correlation I mentioned > above, this shouldn't be a problem as long as each chunk is a multiple of 6144 bytes (for converted AC3 files). The sync information is at the start of each frame, so the decoder shouldn't have to fall back to re-sync'ing if whole frames are always used. Andy: an alternative which you may not have considered is to rip separate AC3 files, encoding each one separately, then join the WAVs back together (just a matter of writing a new header containing the combined payload lengths and concatenating the payloads themselves). Generation of the CUE sheet would then be starting from a known set of WAV sizes... this might be useful if the source AC3 files have variable frame sizes and you don't just have frame numbers to go on. (Disclaimer: I haven't tried the conversion with such AC3 files although I don't see why it wouldn't work. As usual, I'll be interested to hear about any results and can patch the utility if it doesn't just work.) -- smst ------------------------------------------------------------------------ smst's Profile: http://forums.slimdevices.com/member.php?userid=752 View this thread: http://forums.slimdevices.com/showthread.php?t=19260 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
