"VCDXBuild failed to create a bin/cue file"

[DDogg]

I have been researching a "VCDXBuild failed to create a bin/cue file!" error. I think I have traced it down to some corrupted files in the \bbMPEG directory. {this was incorrect information, It turns out it was specific to my machine. Please see below]

[r6d2]

Originally posted by DDogg
This may turn out to be incorrect information. I am getting the same error again. Seems to be caused by a bad packet in the mpg.
I've been getting jerky mpgs lately. Don't know why. I thought it was my burner, but when checking the images with PowerDVD the problem is still there. Are we stretching CCE too much with RoBa, or is it just a muxing issue?

[r6d2]

I keep on getting hardware errors at burn time/play time, no matter the media I try or the burning speed I try. Suspecting a hardware error, I even tried another burner. I'm burning "Burn image" with Nero 5.5.

PowerDVD still plays with some problems the mounted images, but seems more resilient than my standalone.

I ripped the SVCD image to check the mpg directly and I got the following log from VCDEasy:

[VCDxRip.exe]
GNU VCDImager 0.7.12
file EXTRA/DVD2SVCD.XML
file EXTRA/SVCDINFO.TXT
SVCD detected
extracting EXTRA/DVD2SVCD.XML to _extra_dvd2svcd.xml (lsn 536, size 10884, raw 0)
extracting EXTRA/SVCDINFO.TXT to _extra_svcdinfo.txt (lsn 542, size 3810, raw 0)
extracting item0001.mpg... (start lsn 225, 1 segments)
extracting item0002.mpg... (start lsn 375, 1 segments)
extracting avseq01.mpg... (start lsn 694 (+360046))
cn +edge @694
entry point @28480 (329.581933)
entry point @51840 (563.815933)
subheader: no realtime data anymore @52106
truncating file to 51412 packets
writing xml description to `E:\RIPInstinct\videocd.xml'...
done
The resulting main mpg is just 113-MB, and plays perfectly up to the exact same point where the players start to show bad frames, jitters, or bumps.

The VCDXBuilder_log and the dvd2svcd_log did not record any muxing or building errors. Unfortunately, the bbMPEG log is not saved (or I don't know how to save it)

Is anyone experiencing this? Any clues on what may be happening?

[DDogg]

What got me thinking it was bbmplex was vcdeasy, when using it to create bin/cue, always failed and showed a bad packet on those mpgs that failed creating an image in d2s. If I then did a manual mux in bbmpeg, and then did a d2s svcd image restart, I would not have problem making the image. All bbmpeg settings in D2s seem to be the same as in the manual version so now I am stumped (for a while).

VCDEasy log where I am trying to build an image from the mpg created by D2s. Failed.
[VCDxBuild.exe]
GNU VCDImager 0.7.12
initializing libvcd 0.7.12 [cygwin/i686]
changed volume number to 1
changed volume count to 1
changed restriction number to 0
changing 'next volume use sequence 2' to 0
changing 'next volume use lid 2' to 0
changed volume label to `SUPER_VIDEOCD'
changed publisher id to `VCDEASY_V117'
changing 'update scan offsets' to 1
changing 'relaxed aps' to 0
adding pbc (Selection-000/2)
adding pbc (Selection-end/3)
sequence count 1
adding sequence #0, D:\test24\bbMPEG_Muxed_File00.mpg
unexpected start code 0x0000010c
pos != buflen (2321 != 2324)
pts start offset 0.213367 (max pts = 2518.645944)
playing time 2518.432578
scanning mpeg sequence item #0 for scanpoints...
already scanned... not rescanning
audio stream #0 has sampling frequency 48000 Hz (should be 44100 Hz)
pbc: psd size 56 (extended psd 0)
iso9660: highest alloced sector is 232 (using 300 as isosize)
OGT streams available: 0 0 0 0
writing track 1 (ISO9660)...
'update scan offsets' option enabled for the following tracks!
writing track 2, MPEG2, NTSC 2/3 D-1 (480x480/30fps), audio[0]: l2/48.0kHz/128kbps/stereo ...
non-MPEG1 audio stream header seen
unexpected start code 0x0000010c
pos != buflen (2321 != 2324)
invalid mpeg packet found at packet# 68406 -- please fix this mpeg file!
[17s 141ms (VCDxBuild.exe)]
VCDEasy log where mpg has been created by a manual mux of the MPV and MP2 created by D2s. Success.
[VCDxBuild.exe]
GNU VCDImager 0.7.12
initializing libvcd 0.7.12 [cygwin/i686]
changed volume number to 1
changed volume count to 1
changed restriction number to 0
changing 'next volume use sequence 2' to 0
changing 'next volume use lid 2' to 0
changed volume label to `SUPER_VIDEOCD'
changed publisher id to `VCDEASY_V117'
changing 'update scan offsets' to 1
changing 'relaxed aps' to 0
adding pbc (Selection-000/2)
adding pbc (Selection-end/3)
sequence count 1
adding sequence #0, G:\test.mpg
pts start offset 0.213367 (max pts = 2520.931567)
playing time 2520.718200
scanning mpeg sequence item #0 for scanpoints...
already scanned... not rescanning
audio stream #0 has sampling frequency 48000 Hz (should be 44100 Hz)
pbc: psd size 56 (extended psd 0)
iso9660: highest alloced sector is 232 (using 300 as isosize)
OGT streams available: 0 0 0 0
writing track 1 (ISO9660)...
'update scan offsets' option enabled for the following tracks!
writing track 2, MPEG2, NTSC 2/3 D-1 (480x480/30fps), audio[0]: l2/48.0kHz/128kbps/stereo ...
non-MPEG1 audio stream header seen
MPEG packet statistics: 143180 video, 17586 audio, 0 zero, 0 ogt, 1 unknown
writting post-gap ('leadout pregap')...
finished ok, image created with 161367 sectors [35:51.42]
[23s 625ms (VCDxBuild.exe)]

[23s 750ms (All tasks, and user interactions if any)]

[r6d2]

Originally posted by DDogg
[B]What got me thinking it was bbmplex was vcdeasy, when using it to create bin/cue, always failed and showed a bad packet on those mpgs that failed creating an image in d2s. If I then did a manual mux in bbmpeg, and then did a d2s svcd image restart, I would not have problem making the image. All bbmpeg settings in D2s seem to be the same as in the manual version so now I am stumped (for a while).

Did you have a look at bbMPEG's log window during muxing? Did it show anything unusual when running from D2S?

[DDogg]

yes I did, no warnings and everything seemed as it should be, except I end up with a mpg that will not allow a bin/cue to be made from it.

[r6d2]

Uh... Any ideas? Do you think this may have anythink to do with RoBa?

[jsoto]

So, the problem seems to in bbmpeg output..

How did you do the manual mux?. Did you use RunbbMPEG?. If yes, did you "load settings"?

I usually run manually Runbbmpeg and push "load settings" from the ini file saved by D2S.
BTW, I'm using the patched bbmped dll for XP (but only in the manual case).

======== A typical log file ==========

Saving bbMPEG settings: C:\Program Files\DVD2SVCD\bbMPEG\default.ini
.............
Executing RunbbMPEG. Commandline:
"C:\Program Files\DVD2SVCD\bbMPEG\RunbbMPEG.exe" "F:\SVCDsegu\bbMPEG_Muxed_File.mpg"
======================================

jsoto

[dvd2svcd]

Mostly a reply to ddogg:

1. I have not touched bbmpeg or runbbmpeg in a very very long time.
2. The problem must be something with the settings in dvd2svcd.
3. Have you tried to double click the svcd radio button in bbmpeg advanced tab. See if some of the settings changes (double click = default values, which I haven't touched either in a very long time).
4. Check the audio and video encoder settings.
5. Also, your solution in the first post of yours sounds weird, because what I have on the homepage to download and what I have in the build is 100% the same (or so I hope, because if it's not, then I have seriously screwed things up).

Basicly, I'm at a loss, because nothing I have done in this version should do what you describe.

[DDogg]

I don't understand it either and I wish I had not put up that solution. It may be that I have been experimenting with DGs mpeg2dec, but it has never been a problem before. I'll keep looking on my end. Since I saw other reports of the same thing I thought it might have been some corrupted files in the package.

[DDogg]

Well I think I have pinned down my particular problem. Whether it is machine specific or global I don't know yet.

Here is my logic: Remember, the problem was not in VCDXBuild, rather the failure in VCDXBuild is caused by bad packets in the mpg. In other words, a bad mux fouls up VCDXBuild. This led me to think:

When I had this problem the working dir was always on my stripped drives (software stripe XP Pro). So, I copied the dir to my C drive (unstripped), did a search and replace in all the ini and d2s files changing the "D" to a "C". Restarted and no problem with image building. Good mux and good images.

LATER: more interesting

As said, I made a copy on my C drive and everything worked. So then I went to my D: drive (stripped), where the original working dir still existed, and did a restart from mux and got the same old failure "VCDXBuild failed to create a bin/cue file!"

Now I am thinking either the stripped drive is corrupting data or bbmux is having a problem with the much higher data transfer speeds.

So, I then used the original dir on the D drive but edited the dvd2svcd project file.d2s and changed FinalbbMPEGFileName=c:\mydir\bbMPEG_Muxed_File so that the mux mpgs would be written to my C drive, but the images still be written to my D drive. I then did a restart from mux and had no problem. Good mux, good images.

I think we can then say then that the stripped D drive did not have corrupted files or corrupted read of data. Rather it would seem that bbmplex cannot handle the faster read/write or, perhaps something is corrupting the mux on write. That may be the stripped drive or as said, bbmux itself.

I do understand this is hard to believe...but can anybody refute my logic and help me think this out more?

[r6d2]

Originally posted by DDogg
I do understand this is hard to believe...but can anybody refute my logic and help me think this out more?
I have had the same problem and my partitions are not stripped. I only have one drive so I cannot test your thesis either.

However, I suspect bbMPEG may have problems with too high/too low data transfer rates. I have read something about either bbMPEG or VCX build not liking very defragmented drives, which leads to odd data rates.

I've not been able to reproduce the problem at will. I just double check the images as a workaround. It has not happened again.

I though a post from w00kie pointing out that CCE is not good at handling low biases (high variations of BR) because of VBV issues could be related, but he did not expand the idea any further. I'm using bias=30 (default) just in case.

Still lost and trying pagan solutions.

[DDogg]

Well, more progress. I replaced my Silicon Image 0680 based raid card (only used for extra IDE ports, not raid) with a Maxtor-Promise ata133 card and the bad mux problem went away. Even so, I'm not yet convinced it was the raid cards fault as the Maxtor is not nearly as fast as the SI 0680 - 40,000k/bs vs 50,000 kb/s. So, it may still be the speed is fouling BBmux up or it may be the card. Still in a quandary and trying to think of a way to pin it down.

Basically, I need somebody with another Raid 0 setup, either IDE or Sata, to try doing an encode on their striped set and report back whether image building is successful.

[DDogg]

Well I think I finally put a stake in the heart of this problem. It does turn out to be machine specific (mine), but I'll put up the details in case anybody researches a similar problem in the future.

Using the Silicon Image (sil 0680 based) add-on ATA controller, one 40 meg WD atapi 5 UDMA 5 and a 40 meg slice of a Maxtor 120 Atapi 7 UDMA 6 in a raid 0 striped setup. My problem was solved by forcing the Maxtor to UDMA 5 mode. After that my muxing errors with BBMux went away and the speed was the same or slightly better than before. Approx 56,000 kB/s.

[r6d2]

Well, lucky you.

Look at this case. Movie: Johnny English. Q=34, 1 CD, bias=30, SVCD.

Mounting the image from disk with CloneCD and playing in PowerDVD: works OK, can watch the whole movie.

Mounting the image with Daemon Tools (I have them both installed), plays OK up to 1h:17m timesequence. Then it stops for some seconds, shows another frame, the stops again...

When burning to a CR-WR (4x) the same behaviour is observed on PowerDVD.

Ripping with VCDEasy from the CD-WR stops at 1:17 too with a "no more real time data" error.

Playing on my standalone, same problem. What can possibly do CloneCD to understand better the mounted image than Daemon Tools and my standalone?

Unfortunately, I don't have the original MPV or MPG, so I cannot test the origin or the error. I will encode it again.

[DDogg]

BTW, I always use bias = 11 and have never had a problem that I knew of.

[Trahald]

I was referring to having a low bias and using the robshot method (ie editing the bitrate by hand).. ive had issues with that in the past (issues meaning bbmpeg warnings - although file seems to play ok.. )
Because of the low bitrates i used, and the small range of svcd bitrates, i would lower the bias as it would HELP me in getting all the areas "green". ive gotten away from that and now my bias is generally 20-30 and things seem to be fine.. although i dont make images so i have nothing to report in that area.