HTOA ripping / multi-core encoding question

[moley6knipe]

Hi, I've got a few questions about HTOA ripping, and how to best utilise both my cores when ripping, if I may?

HTOA
According to daefeatures, my drive (Samsung SH-S203P) will rip HTOA, and indeed if I put such a disc in it tells me there's a HTOA. Do I simply click rip? Or is there something else I need to do? When I've tried it before it errors out - I'll post back with the exact error when I get home.

If not, can anyone recommend another drive with C2 and HTOA? Does anyone know of a standard sized version of the Teac 224 that's been tested for the RipNAS?

Multi-core encoding
I use Ref 13.1, Multi Enc 3, Apple Lossless 8, Lame 3.98, DSP 3. In multi-encoder for both ALAC and lame I've added the ID tag processing DSP. I've ticked "use both cores" (or however it's phrased!) in multi-enc. However when I rip, each track rips, then gets encoded before the ripper moves to the next track. The screenshot here shows one core encoding a track whilst the next track's being ripped - how do I get it to do that, it would save loads of time?

Thanks!!

[Spoon]

Re: HTOA ripping / multi-core encoding question

Daefeatures is not always correct, or might be firmware version dependant.

Multi-encoder would be using the multi-cores, not CD Ripper in this instance (otherwise Multi encoder might want to use 2 cores and cd ripper have 2x multi-encoders = 4 cores).

[moley6knipe]

Re: HTOA ripping / multi-core encoding question

Ah, I see - so on a quad-core it would be encoded and ripping at the same time even using multi-enc.

So if my drive does support HTOA, it should be as simple as click rip (assuming i've selected the HTOA)? And if that fails the drive is not actually HTOA compatible?

So anyone got a recommendation for a desktop drive that will rip HTOA?

Thanks...

[Porcus]

Re: HTOA ripping / multi-core encoding question

So if my drive does support HTOA, it should be as simple as click rip (assuming i've selected the HTOA)? And if that fails the drive is not actually HTOA compatible?

Yep, just try -- but listen to it afterwards! I think that some drives will pretend to rip, and give you zeroes only. Of course, if your CD has a HTOA containing only silence, there is no way to tell ... not that I have heard of any such though. You might want to look up http://en.wikipedia.org/wiki/List_of...a_hidden_track and see if your CD is quoted as having a bonus track in the "pregap".

As for recommendations ... it could even be firmwareversion-dependent so if my BrandX ModelY works, the one in the stores might not necessary.
(You also want one drive which supports C2 error pointers. By the way, I use a laptop, so any recommendation from me is no good I guess.)

[moley6knipe]

Re: HTOA ripping / multi-core encoding question

Brilliant, thanks. Glad I'm not going daft, then!

I've 'calibrated' drive with dBpoweramp and it reports as supporting C2. It's generally a good drive but I've found about 10 discs in my collection with HTOA, so worth buying a drive that can manage them.

Doesn't appear to be a desktop version of the 224 that Spoon tested for the RipNAS, well not that I could find!

My search continues...

[Spoon]

Re: HTOA ripping / multi-core encoding question

The Teac drive for RipNAS possibly does not support HTOA, but then again it does not need to for headerless ripping.

[VernonAMiller]

Re: HTOA ripping / multi-core encoding question

Ah, I see - so on a quad-core it would be encoded and ripping at the same time even using multi-enc.

Actually, I thought so too...so I went out and bought a quad-core processor to replace the dual-core in my workstation, hoping it would make the whole process faster. However, it doesn't seem to work that way if I use Multi-Encoder.

Now that I have my quad-core installed, if I don't use Multi-Encoder and just encode to FLAC, I have seen it use at least three CPUs at once (two were doing encoding, and the third was ripping). So, that's great and what I expected.

However, if I use Multi-Encoder, then Ripper doesn't seem to fire off any new ripping threads until the current multi-encode is completely done. So, in effect, when Multi-Encoder is being used Ripper becomes single-threaded; it waits for Track 1 to finish completely (ripping, then Multi-Encode) before going on to Track 2.

This could be a bug, or it could be by design. It is tricky to do thread scheduling when you have multiple independent modules that are multi-threaded.

Anyone know if this is a bug or by design?

[Spoon]

Re: HTOA ripping / multi-core encoding question

Multi-encoder has a multi-cpu option, is it checked?

[Buck Swope]

Re: HTOA ripping / multi-core encoding question

Multi-encoder has a multi-cpu option, is it checked?

Spoon

I can confirm that when using the multi-encoder codec, the multi-cpu option doesn't seem to work. I have tried it both ways, checked and unchecked... and it still behaves as if it were a single core.

I'm using a quad core as well.

[Spoon]

Re: HTOA ripping / multi-core encoding question

Multi-Encoder is multi cpu within the encoder - if you have plenty of spare cores you can ask CD ripper to allow multi cores with the Multi CPU Force DSP effect.

[EliC]

Re: HTOA ripping / multi-core encoding question

The Teac drive for RipNAS possibly does not support HTOA, but then again it does not need to for headerless ripping.

why would headerless ripping mean it doesn't need HTOA support?

Speaking of which, will we be getting batch ripper support for HTOA or at least an option to flag and set HTOA discs aside?

[VernonAMiller]

Re: HTOA ripping / multi-core encoding question

Spoon

I can confirm that when using the multi-encoder codec, the multi-cpu option doesn't seem to work. I have tried it both ways, checked and unchecked... and it still behaves as if it were a single core.

I'm using a quad core as well.

Thanks Buck for confirming this behavior.

Multi-encoder has a multi-cpu option, is it checked?

I've tried it both ways and it doesn't change the apparent behavior either way; Multi-Encode still has to finish completely on Track n before Track n+1 will start ripping. I only have two encodes going on in Multi-Encode (FLAC and MP3, for instance), so in theory it should only be using at most 2 cores at a time.

Since there's just one progress bar that is shown for the entire "Encoding" process, I can't really tell if checking "Multi-CPU" in Multi-Encode is really changing the way it works or not. I suppose I could try timing a given rip with it enabled and then disabled, so I could deduce whether it's actually making a difference during encoding or not.

Multi-Encoder is multi cpu within the encoder - if you have plenty of spare cores you can ask CD ripper to allow multi cores with the Multi CPU Force DSP effect.

So, by using Multi CPU Force DSP, I can allow CD Ripper to start ripping the next track even while Multi-Encoder is still encoding? That isn't obvious to me from the help text for that effect, but I'll sure give it a try.

Vernon