R12 CD ripper is a memory hog?

[TarkusShakti]

I have a dual-cpu system with 1Gb of memory. While running the R12 "reference" CD ripper I see that the CDGrab.exe is using 409,536K and each ScanningProcess takes up 16,500K each. There are also two CoreConverter processes which take 3,034K. This totals to 448,000K.

This amount seems excessive to me. My system keeps displaying "out of memory" errors and some applications crash [but only once has the CDGrab process died.]

If there was a provision in "reference" cd ripper for limiting the number of cpus; I'd be able to cut in half the memory usage (I, believe.) But there isn't...

What to do?

TS

[LtData]

Re: R12 CD ripper is a memory hog?

What format do you rip to?

[TarkusShakti]

Re: R12 CD ripper is a memory hog?

What format do you rip to?

From Flac to m4a (nero aac)

TS

[LtData]

Re: R12 CD ripper is a memory hog?

What format were you ripping your CDs too when you recorded the memory usage? Were you using secure or burst mode?

[TarkusShakti]

Re: R12 CD ripper is a memory hog?

What format were you ripping your CDs too when you recorded the memory usage? Were you using secure or burst mode?

secure mode...

[LtData]

Re: R12 CD ripper is a memory hog?

What format were you ripping the CD to, FLAC or m4a?

[TarkusShakti]

Re: R12 CD ripper is a memory hog?

What format were you ripping the CD to, FLAC or m4a?

Sorry I made a mistake. CD ripper is CD -> m4a, secure mode

My batch jobs are flac->m4a.

TS

[LtData]

Re: R12 CD ripper is a memory hog?

i think the CD ripper takes up some memory as it normally does a "Rip to RAM" function where the CD rip is stored in the RAM and then encoded. Of course, since Reference supports multi-CPU encoding, you will be storing two CD rips in memory. This explains some of the heavy memory usage.

And no, there isn't a way to turn off "Rip to RAM" in r12.

[Spoon]

Re: R12 CD ripper is a memory hog?

Yes for 2 passes they are stored in memory, each. The 2nd track will do the same so it is possible the memory used is

4x largest track length in secure mode.

[TarkusShakti]

Re: R12 CD ripper is a memory hog?

Yes for 2 passes they are stored in memory, each. The 2nd track will do the same so it is possible the memory used is

4x largest track length in secure mode.

Can we get some relief from this and other issues; by having the ability to use a user definable number of cpus in "reference?"

"reference" is starting to look like a hindrance...I paid for these problems!

TS

[Spoon]

Re: R12 CD ripper is a memory hog?

The standard version will use exactly the same, it encodes in the background whilst ripping the next track in secure.

Windows is a modern operating system, if I wrote this to a temporary file you would be happy and think great no memoy hog, but there is no point as if your system is low on memory windows will write it to the swap file, exactly the same, just that if there is the free memory (many systems these days have > 512 MB) there will be no HD wear and tear.

[bhoar]

Re: R12 CD ripper is a memory hog?

In addition, the data reported by the task manager, esp. in the area of memory consumption, is often very misleading. I usually use Process Explorer and look at the results of several memory and paging statistics before deciding whether a process is really causing a memory issue or not.

-brendan

[TarkusShakti]

Re: R12 CD ripper is a memory hog?

The standard version will use exactly the same, it encodes in the background whilst ripping the next track in secure.

I thought only "reference" used multiple cpus. I thought that I could cut my memory usage in half by only using one processor. Your statement seems to contradict this...

When can we control the number of cpus applied to the task?

TS

[Spoon]

Re: R12 CD ripper is a memory hog?

Standard will not encode using 2 cpus, but it will rip on one (until encode) then encode on 2nd cpu.

The design is for optimal usage of the computers resources, changing it would be slower and use the hard disc more, which would slow down other applications.