Ripping (X)SVCD with Toast vs VCD Copy X

[havema-1]

It seems that although it is faster to rip (X)SVCD with Toast(*), ripping with VCD Copy X is more reliable:

I just tried to re-burn an old PAL 352x576@48kHz XSVCD to DVD. The Toast-ripped MPEG2 was recognized OK with apps like QT Player with MPEG PB component, MPEG Info X 0.2 and mpgtxwrap GUI.

But after demuxing it with MoreMissingTools' mpgtx, those apps didn't want to deal with it (and MissingMpegTools' vcdxgen didn't want to generate VOB from the ripped MPEG2 either).

I then ripped with VCD Copy X, demuxed, remuxed as DVD, authored with MissingMpegTools, burned with Toast, and the disk played OK with Pioneer 444.

So obviously ripping with Toast introduces some flaws to the MPEG?

(*)Ripping with Toast: select Copy and Save as Disc Image, rename the disc image to *.bin and use vcdXrip in GNU vcdtoolsX to extract the MPEGs from it.

[Frobozz]

Technically you aren't ripping from Toast if you're ripping from a Toast-saved disk image in Disc Copy mode. The Toast disk image isn't any different from a disk image created using Apple's Disk Copy or Disk Utility. It is the exact data from the source saved in a disk image format. Toast does nothing to the data itself.

To prove it's the same as an Apple disk image, change the file type from .toast to .img and mount with Disk Utility (in !0.3). See, no difference.

Actually, you don't even need to change the type extension if you use this shortcut to mount disk images (at least this works in 10.3.2): Hold down the control key as you click on the Toast or Apple disk image file. Choose Open With... DiskImageMounter. Cool.

[galactica]

The Toast disk image isn't any different from a disk image created using Apple's Disk Copy or Disk Utility. It is the exact data from the source saved in a disk image format. Toast does nothing to the data itself.

Not always the case. though this does hold true for vcd's as far as i can tell, it does not for things like game backups. Try to get a game to recognize a backed up .dmg mounted with diskutility - it cant sometimes. But make the image using toast and mount it with toast, and it does!
something is differnet

PS. its not toast thats introducing the flaw. As pointed out you are not ripping the .mpeg with toast. Rather, if you are using toast to save the disk to a disk image, its the apps you use on the image that is "ripping"

try vcdtoolsx, i never had problems with it. Plus, the resulting muxed mpeg file can be directly imported into sizzle for your authoring to .vob

[havema-1]

> .dmg mounted with diskutility - it cant sometimes. But make the image
> using toast and mount it with toast, and it does!

Yes, Toast and DiskUtility seem to mount at least some images differently. Sometimes you can do more (i.e. other applications treat them as real disks) with Toast-mounted images, regardless what made the image in the first place.

> try vcdtoolsx, i never had problems with it. Plus, the resulting muxed
> mpeg file can be directly imported into sizzle for your authoring to
> .vob

I used vcdtoolsX to extract the MPEGsfrom two XSVCDs imaged with Toast but both failed to play after demultiplexing (mpgtx).

I wonder whether the CD-ROM XA "Mode 2-Form 2 block" format with 2324/2352 B per sector for MPEG confuses vcdtoolsX -- does .bin use the same structure?

[galactica]

I have never had problems like you mention
1. save disk to .toast image
2. rename .toast image to .bin image
3. extract mpeg using vcdtoolsx from the .bin image
4. demux using bbdemux or ffmpegx
(i have never used mpgtxwrap to demux so maybe thats the prob?)

give the demuxing a try with ffmpegx, just load up the .mpeg into the 1st browse tab then click demux