very slow muxing - why?

[ux-3]

This is something one wouldn't notice unless one uses two encoding machines in parallel: The muxing stage of dvd2svcd occurs with an irritating difference in speed on the two machines. Their CPUs don't differ much, we talk xp2000+ vs xp1700+. Both have 256 MB Ram and both have plenty of free HD space (10+ GB). I even defragged the slower one to make sure there is continous space available. Both hard disks are of the 7200 type. The slow one is a 40 GB drive by Samsung, hooked via U-DMA 100, the faster one is a IBM 80 GB also via U-DMA 100. On the IBM, you can painlessly watch the muxing in real time, it only takes 1-3 minutes. On the Samsung, it takes much longer, perhaps 10 or 15 minutes. Both systems are relatively clean win98se installations.
Other stages of the processes don't differ much in speed (15% perhaps).
Perhaps someone did come across this problem. I will time the muxing of a typical 820 MB CD and post it here, so that it is possible to compare the times.
thanks for input on this!

[Boulder]

The first thing that comes to mind is that check the DMA (enabled/disabled?) in the System applet. I don't use any chipset specific IDE drivers on my Win98SE installation, and the standard DMA mode seems to be faster than UDMA which can be enabled by installing the IDE drivers (talking about KT333 here).

The drives could also have a different amount of cache but I don't think it should affect the speed that much.

[ux-3]

I checked that early, it is DMA enabled.

The fast Mobo is an Epox with Via Drivers.
The slow one is an Elitegroup k7sa5 with SIS drivers. Perhaps I will try to dump those drivers after my next backup and see if it changes anything.

By the way, I just looked at the log files: bbmpeg did run for about 15 - 20 minutes on the slow one. The mchine is pretty well unaccessible while muxing. Won't wake up from screensaver for instance, even if priority is set on idle.

[UltimateDBZ]

If the slow machine is running on NT/2000/or XP, then do the 3-finger-salute (Ctrl+Alt+Del) and go to the processes tab. Then go to bbMPEG and right click on it and go to Process Priority. Then set the priority down further than it is. This should give priority to Windows and other applications allowing the machine to at least be accessible during the muxing process.

[ux-3]

No, I am using Win98se on both machines

[chainsaw135]

Maybe you could the set the Process Priority in dvd2svcd. Click on the Misc Tab and select"Idle" instead of the Default "Normal"... just my 2 cents. One more thing, i would also upgrade both machines from 256mb to 512mb when i did i noticed a huge improvement in performance while they were encoding.

[Labersack]

After my experience muxing time depends mostly on HDD speed. Try some benchmark for your HDD (I myself use h2benchw, good tool, available from ftp.heise.de/pub/ct/ctsi/h2benchw.zip . Maybe because of some unknown reason your disks differs much in speed.

[ux-3]

Thanks for the input. Both machines are set on idle. I will resume muxing with the setting on high, see if it increases performance. I did use 512 MB for a test once, cce was not really any faster, so I didn't bother. I also think it has to do with the HD. While both run on 7200 rpm, my impresion is that the IBM is significantly faster. Perhaps the cache management is more suited to the task? I'll try the prog you mentioned...

[chainsaw135]

Yeah cce wont be much faster with 512 v's 256, but your computer performance will be alot better, you can multitask much easyer, thats what i meant when i said "the performance will be much better".

[ux-3]

I genuinely believe that I can much better multitask with two PCs, each with 256 MB than just one with 512 MB :D
With Win98se, there isn't much improvement with more mem. I had 256+128 in one one machine for 6 months and I din't notice it when it was there, and (more important), I also didn't notice it when it was gone again.

[chainsaw135]

Yeah you are totally correct, forgot about the limitation of win98. But this subject is prolly out of the scope of the forum itself not sure if you'll find the answer, if you do let us know:P You might wanna check over to "OCWorkBench" Maybe this link will help http://www.ocworkbench.com/index.stm
I'll post my muxing times on the next encode here are the 2 machines i'll be using for the test.
K7S5a, xp 1800, 45gig, 7200rpm, 8.5 seek 512mb of ram with windows xp
Soltex DRV5,xp 1900, 80gig, 7200rpm, 8.5 seek 512mb ram with windows xp
They are networked together, i plan on doing 1 encode at the same time with each machine...
ux-3 if you would like me to try something else, just let me know maybe i will also have the same enomily as you.

[ux-3]

I just watched a mux of 830 MB MPG. When doing the video and audio scans, the difference in speed is not striking. HOWEVER, the muxing proceeded at more than 1% a second! The whole actual mux took about a minute! Basically, it went almost as fast as the scans. After 3 minutes something, the bbmpg stage was done completely. We are talking about muxing 730 MB video and two audio tracks of perhaps 50 MB each.

One thing for sure, there is no second hard disk in the PC. And no second device on this IDE channel.
The slow PC has a DVD stuck on the same IDE, which could be the problem. And it takes at about 6-7 seconds for each %.

Now this is what I call a performance difference!!
If it is the HD, then it'll be replaced by an IBM soon...

Could we gather a few more muxing times, from other potent or aged machines? I am getting curious...

@labersack:
Downloaded proggie but two probs:
Manual doesn't mention win98 at all and
for write tests, HD needs to be without format (?). Since pure reading situations show no significant differences, I need another app to test, perhaps I try sisandra?

[UltimateDBZ]

Sandra is good, as is the HD benchmark that comes with MPower. Just do a search for either, both are free.

[magubbi]

I don't think it's a big deal.

Relative to the entire DVD->SVCD process, 10-15 minutes is nothing to change a hard drive over.

If you do get a new one, I would be glad to take your old one.

[chainsaw135]

The testing i did was with the same movie, because thats the only way i feel your going to get an accurate results. I didn't see much of a difference in speed when mux/cutting I used my soltex xp1900 v's my k7s5a xp1800. So the only thing i can think of is 1 of your hardrives is just plain out faster then the other. But with out the technical proof i can't be 100% on that either.

[Labersack]

Sorry, I didn't read your first post very well, so I haven't see that you are using win98. I have killed this OS from all my machines, because win2k is much more stable, so I didn't think swomeone else could still have it . ;)
The program I mentioned won't work under this OS, you have to look for another benchmark.

[UltimateDBZ]

To clarify: Hard drive speed is affected by much more than the much-advertised rotational speed and UDMA transfer rate. Though these two factors are very important (and you should get 7200 RPM and ATA-100 at the minimum), they are not all that goes into HD speed. Transfer rates are becomming less and less important, as was very notable in the recent ATA-133 release, gaining mere megabits a second more than its predecessor. With the future release of SATA (serial ATA), transfer rates will again become a revolving factor. SATA will start at 150mb/s, and top out at an eye-popping 600mb/s. Only with RAID can the full transfer potential of a HD be realized, and even then it is only literal speed, the advertised 66, 100, and 133mb/s are merely theoretical speeds and are VERY rarely achieved. Far more important at this point is rotational speed, of which you should have a minimum of 7200 especially for video encoding tasks. 5400 is just plain outdated. If your wallet can suffice it, a 10000 or even 15000 RPM SCSI HD will achieve much better speeds, as disk access time will be very very short. However, other factors such as disk cache, which is just now being popularized mainly because of Western Digital's line of HDs now using 8mb caches instead of the customary 2mb cache, are also very vital in determining overall disk speed. In conclusion, you should read the detailed version of vendor's spec sheets before purchasing a HD from any manufacturer, and if possible, compare it side-by-side with another big name maker. If you don't really have a choice (i.e. purchasing from an OEM like Dell, Gateway, IBM, HP, etc.) then just do the best you can. If possible, don't buy a HD along with the machine, and buy it separately.

[ux-3]

Well, all this being said, what are the times you guys have for the actual muxing stage, not the scanning before and after?

[ux-3]

Just a polite reminder...
Coulds someone please post the time for the actual muxing process for a CDR80 (preferable) and / or the time the SVCD logs indicate bbmpeg active, as well as the HD specifics. I would like to nail the problem down, but before I take apart one PC, I'd like to find out if my slower PC is slow by comparison to other similar machines. Please lend a hand.
greetings
ux-3

[Jason28]

When I get home tonight I will post some stuff and let you know.

[Johnny Casaba]

ux-3, I am not an expert, but I believe your problem is having the DVD-Rom and hard drive on the same IDE chain. When 2 devices share the same channel, the transfer speed will only be as fast as the slowest device. Try putting the hard drive alone on one of your IDE channels. Hope this helps.

[Jason28]

Sorry ux-3 I thoought that I had some log files on my comp from a full length movie but I didnt. As soon as I do anther one I will post the times here.

[ux-3]

After I have patiently waited 3 months, I would like to solve the problem and hence move this thread back up on top. Could people please post the muxing time they have with their HDs? Using a single full cdr80 as base of comparison. Or how many seconds it takes in that case for a 1% increment in muxing (not scanning. I am quite willing to make more test, but before I Move an OS from one HD to another and back up 10+ CDRW, I would like to know a little more about what speeds others get on a current system.