Beta: [Multi-Processor Multi-Encoder]

[Spoon]

For those with multi-processor computers, or new dual core cpus. Encode to two different formats at the same time, effectively encoding at twice the normal speed.

Download:

http://www.dbpoweramp.com/beta/dBpowerAMP-codec-multi-processor-multi-encoder.exe

160KB

NB there is currently no help file, and this codec will work until July 2006 only (it will be part of dBpowerAMP reference then).

[LtData]

Alright, Spoon! I'll test it out here in a bit on my AMD Athlon64 X2. :)

[LtData]

Works beautifully. Encoded a CD to Monkey's Audio at Normal and to Ogg b4 SSE2 encoder q5 in 3 minutes. That's two minutes faster than just the multi-encoder.

[toolburn]

System: P4 D 830 (3GHz)
OS: Windows XP x64
CD Drive: Pioneer DVD-RW DVR-109
HD target: WD 250GB SE - USB 2.0 connected

CD: Franz Ferdinand
Size: 391MB
AccurateRip ID: 00100207-8909190b

dBpowerAMP Music Converter - Audio CD Input

Run 1
Encoder: Multi-Encoder
Format 1: Windows Media Audio V9.1 - VBR Quality 75, 44 kHz, stereo VBR
Format 2: FLAC 5.3 - compression level 5
Speed: 19x Real-time
Time: 3min 20sec

Run 2
Encoder: Multi-Processor Multi-Encoder
Format 1: Windows Media Audio V9.1 - VBR Quality 75, 44 kHz, stereo VBR
Format 2: FLAC 5.3 - compression level 5
Speed: 18x Real-time
Time: 3min 26sec

Run 3
Encoder: Wave
Format: Wave 16bit 44.1KHz Stereo
Speed: 32x Real-time
Time: 1min 38sec

I re-ran Run 1 and Run 2 a couple more times and every time the Multi-Processor Multi-Encoder was a few seconds slower then the Multi-Encoder.

[Spoon]

Odd, what if you run it 20 times, it will take over 4 minutes?

[toolburn]

Sorry for any confusion - I've edited my post.

On each run the times were about the same but the Multi-threaded Multi-encoder is always slower by a few seconds than the Multi-encoder.

[Spoon]

The reason is that WMA will use the 2 processors in anycase (it creates a sub encoding thread), try mp3 and ogg vorbis and time those two.

[LtData]

OK, this is interesting. I can convert a CD to Ogg Vorbis b4 SSE2 by itself, but if I try to convert to Monkey's Audio and Ogg Vorbis b4 SSE2, dMC crashes every few songs. It has done this on 4 CDs I have tried to rip. It also did it when I ripped to Monkey's, Vorbis, and WAV. It normally crashed just before it created the .ogg file and while the other two files were created, they were empty. It seemed to do this every few tracks.

What it seemed to do a lot was that it ripped one track to RAM, was converting it, and ripped another track to RAM which might have over-written the previous track causing the in-place conversion to fail. I say this because when it would fail, I would get empty files for the last 2 tracks it tried to rip.

Any ideas?

[Spoon]

Nothing springs to mind, this codec is pretty much just a test bed, dMC R12 already has a built in multiprocessor encoder which is better as is native (must release this next beta of R12)...

[DannyKudos]

I keep getting the following error just at the end of a CD Im ripping to FLAC and aoTuv b4 SSE2. (This is my first attempt at using this codec as I have just acquired a duocore laptop)
[MusicConverter.exe - Application Error]
The instruction at "0x7cp11e58" referenced memory at 0x000000016. The memory could not be "read". Click OK to terminate the program.

[Spoon]

Ripping to each audio format seperately works?

[DannyKudos]

certainly does, as does using the other multi-encoder

[Spoon]

Due to this code becomming redundant (there is already the multi-processor encoder in R12 alpha, just missing the codecs, they will be added pronto) we cannot bug fix it, as it wouldn't be productive.

[DannyKudos]

no worries i can wait :)

[gameplaya15143]

I hope this doesn't remain an issue in dmc12...

When using 2 CLI encoders for the same codec (I suspect any that use the same extention)... well, I was encoding the same track to Ogg Vorbis twice, each with different settings. Both write to "~dmcout.ogg"!!!! The second instance in the encoding list overwrote what the first one had written, but since the 2nd was of a lower bitrate, the resulting file had the remaining data still attached to the end.

You should have make it write:
~dmcout.ext
~dmcout2.ext
etc. etc.

I haven't tested, but the other multicodec thing probably has the same problem.

[Spoon]

You will have to remind me when the new CLI is witten for R12