Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mirko]

Hi,

in the other forum, we discuss a little about ripping features (EAC vs. CDex).

I would like to suggest integrating parallel encoding and multidrive-ripping-support into MJ9. This would help quite a lot of people, who have more than one drive to rip from and who have enough processing power to encode more than one file in parallel.

In my case my CPU is quite able to rip from two drives during encoding 4 songs at the same time. Sure there is nearly no power left for other uses, but this doesn't matter, because I usually rip when I watch TV or care about other... things :-)

[RemyJ]

I agree 1000%

[JohnT]

Just to clarify your enhancement request:

MJ currently has two ripping modes:
1. rip/encode simultaneous one CD track at a time
2. serial rip/encode one track at a time (rip the track, then encode it, then move on to the next)

You would like to add a third mode with these features:
1. ripping and encoding would occur separately, the ripper processes would proceed at full speed creating temporary wave files.
2. user can choose the maximum number of CD drives to rip from simultaneously
3. user can choose the maximum number of encoding processes to run simultaneously

Did I get it right?

Question:
1. How much time saving is there? If you rip two CD's with EAC (in burst mode without the "secure" feature), how long does it take compared to MJ ripping the same two CD's in "digital large buffer" mode and simultaneous rip/encode enabled. Of course the Lame encoder settings have to be identical also.

I'm going to run a test on my system, but there are so many factors affecting the final speed that I'd like to see data from other systems.

Thanks,
John T.

[RemyJ]

John,

Check out this thread.

http://www.musicex.com/cgi-bin/yabb/YaBB.cgi?board=general;action=display;num=1032504664

My take is that the current pipelined "rip and encode simultaneous" is the worst performer and the best is rip then spawn encoder and continue ripping.   Over the weenend I reran the tests on another machine (a dual 400mhz box in both single and dual cpu mode) and got the same relative results.

Remy

[Doof]

And while you're add it, add the ability to rip an entire CD into one track, and create a CUE sheet.

[JohnT]

RemyJ-

Sorry, previously I missed the link to the detailed results that you had included in the post. Thanks for providing the comprehensive report. I think we can speed up the pauses that occur between tracks in MJ - a quick fix. We'll discuss the possibility of changing the ripping architecture in MJ.

Thanks again,
John "the ripper" Thompson
JRiver, Inc.

[Mirko]

JohnT:

I will try explaining in detail:

I have two drives (D, H). And I am currently running two instances of EAC. Each of it is assigned to a specific drive. Both EACs-instances rip the CD with digital secure ripping and when a track is finished, it is send to a "sub-instance lame". So if a track is finished ripping, the lame process gets going without interrupting the rip of the next song. I assigned EAC a maximum of 2 simultanious lame-instances in one session (this is a custom limit, it might be many more, if Intel would produce more powerfull CPUs), so there are at the max 4 lame processes and 2 EACs-instances running.

And yes, you are right: The ripping goes to a wave file and this one is processed by the next "free" lame-instance _of one EAC-process_. So if the first EAC process has a lame-instance "doing nothing", it can encode the next wave _from this EAC-session only_ (which I personally don't like -> MJs chance!).

MJ could be improved, if it supports ripping from more than one source and sending the ripped waves to lame-processes which run parallel to the normal work. MJ might be notified, if a lame process finished work (think about it as a subtask and remember the tasknumber windows assigns) and can automatically include the encoded file into the library (and tag it, including track#).

The speed improvement is quite a bit, if you have a powerfull CPU and some good space on your harddisc. I usually throw in the CDs to rip as fast as I could and the lame-instances run for many hours after this (without me sitting in front of the machine). After they finished, I usually import the encoded (and tagged, because EAC does this quite good during ripping (after encoding)) files into the MJ database and analyze them and move them to where they belong.

HTH,
Mirko

[dragyn]

Yes the CUE sheet is a must for me. Then I could be using MJ ALL the time.

I think Doof and I are related..maybe a long lost brother or something. We agree on the same things most of the time and use the same skins, rip CDs the same way and usually come up with the same ideas. hmmm...

[Doof]

hehe... the funny thing is, I used to go by the handle of Dragon.

But I got the whole APE\CUE thing from you.

[Endymion]

MJ could definitely be faster at ripping.   EAC rips from the CD continuously and spawns up to a user defined number of encoder processes.   If MJ did this, it would greatly speed up the ripping process for me (I estimate by about a factor of 2).    So no waiting for an encode to finish before ripping the next track, just queue up a bunch of encoding processes.  

-John
Listening to: 'Wayfaring Stranger' from 'Eva By Heart' by 'Eva Cassidy' on Media Jukebox