Fasted Method for Ripping and Reencoding?

[consultant]

I'm experimenting with different processes for ripping and reencoding my Blu-Ray collection. I'm curious other people's methods so I can compare.

So far the fastest process I've found is to rip use DVDFab - I've found it consistently faster than MakeMKV. The reason I don't use ripbot2654 with AnyDVD is that while ripbot is reencoding (to reduce filesize to approximately 1/4 to 1/3 original m2ts size - I do this to reduce storage and bandwidth for streaming requirements)

I've notice that one of the steps that ripbot takes some time to do is to demux the source. So I'm thinking I can further reduce the time by also demuxing prior to ripbot (again, this is all while ripbot is already in the process of encoding another title.)

I've found tsMuxer splits PCM audio into more than one WAV file. I'm now seeing if Useac3to is the better tool to do this because when I am ripping PCM audio, I encode it to FLAC and Useac3to can demux AND convert the PCM to FLAC in one step. So then theoretically I can encode and mux with ripbot and ripbot won't have to demux or reencode the PCM to FLAC.

[stax76]

I think RipBot264 usually demuxes and even decodes which yields to big files and long demuxing and decoding time but is it such a great difference compared to direct conversations? HD stuff takes hours anyway, even with the newest hardware, HD is expensive so why not buy a fast SSD as well?

[primerump]

I'm experimenting with different processes for ripping and reencoding my Blu-Ray collection. I'm curious other people's methods so I can compare.

So far the fastest process I've found is to rip use DVDFab - I've found it consistently faster than MakeMKV. The reason I don't use ripbot2654 with AnyDVD is that while ripbot is reencoding (to reduce filesize to approximately 1/4 to 1/3 original m2ts size - I do this to reduce storage and bandwidth for streaming requirements)

I've notice that one of the steps that ripbot takes some time to do is to demux the source. So I'm thinking I can further reduce the time by also demuxing prior to ripbot (again, this is all while ripbot is already in the process of encoding another title.)

I've found tsMuxer splits PCM audio into more than one WAV file. I'm now seeing if Useac3to is the better tool to do this because when I am ripping PCM audio, I encode it to FLAC and Useac3to can demux AND convert the PCM to FLAC in one step. So then theoretically I can encode and mux with ripbot and ripbot won't have to demux or reencode the PCM to FLAC.


I use BDinfo to find the playlist, tsmuxer to demux the tracks and build a ".m2ts" remux then use handbrake to convert to h264 in mkv container.

[consultant]

I think RipBot264 usually demuxes and even decodes which yields to big files and long demuxing and decoding time but is it such a great difference compared to direct conversations? HD stuff takes hours anyway, even with the newest hardware, HD is expensive so why not buy a fast SSD as well?

I think you missed the point that when you add a job to the queue Ripbot can take a long time to demux. This step is required whether you start encoding or not.

My point was I can rip and demux a dozen BDs during the 6-8 hours RipBot is spending encoding another rip. So when it is done, I can add all the new jobs without waiting for it to demux!

The encoding is very taxing on the CPU, ripping and demuxing is not so it barely effects the encoding speed. So essentially I'm saving hours of time waiting for ripbot to demux each job by using multi-tasking capabilities of the computer to rip and demux at the same time I'm encoding. The reason I have to do it this way is you can't load more than one copy of RipBot into memory at once. Once it is encoding, you have to wait for it to finish hours later before you can load any more jobs.

I'm not worried about demuxing speed. I realize the hard drive is probably the bottleneck when demuxing but demuxing is relatively very fast compared to encoding. I don't think an SSD would make any difference on the encoding speed since the encoding bottleneck probably always the CPU, not the hard drive. Hard drive can spit out 60MB/s which means a 30GB file would take less than 10 minutes to encode if the CPU could encode the file as fast as the hard drive could read the file. Of course that is only the read, so say 15-20 minutes to account for the writing too.