dBpoweramp Music Converter R14 Discussions

[Spoon]

dBpoweramp Music Converter R14 Discussions

[AshenSugar]

Re: dBpoweramp Music Converter R14 Discussions

will it have things like

joining files

splitting by cue

native x64 support

[Spoon]

Re: dBpoweramp Music Converter R14 Discussions

The first two are independent of Music Converter (more codec related).

It will be R15 before native x64 (getting all the codecs to compile as x64 is a massive undertaking, even if the other code such as CD ripper can already compile as x64).

[EliC]

Re: dBpoweramp Music Converter R14 Discussions

looks like it will be time to dig out the box of test discs and hook up some alternative drives!!!

Spoon, at one point you had talked about adding some functions that would require a database, but that was going to be introduced with Renaissance. Will Renaissance still come out before R14?

[AshenSugar]

Re: dBpoweramp Music Converter R14 Discussions

ok encoders i know have x64 versions are
ogg vorbis(aotuv 5.7 and stock oggenc compiled by john33)
Musepack sv8
Lame

Im working to try and get somebody to compile an x64 speex encoder as well.

note, IF you are using an exe encoder to do the work x64 exe's work, BUT you have to set them to run as admin(and possibly compat mode for vista) to get around the error, even with UAC dissabled.

I have found the x64 compile john33 did to bet quite impressive despite having no hand optimized x64 optimizations(those would boost perf alot from what i have seen with other apps)

I know some other encoders have x64 versions as well, but really, I only use the above mentioned for mobile work.

Oh apparently FLAC has an x64 version as well(somebody was just telling me this)

for more x64 compiled encoders you could check mediacoder x64 as most if not all of its encoders are now native x64

i really do wish lancer would re-appear and work on some newer optimized vorbis encoders, his older stuff is quite impressive for speed even today, imagin what he could do with modern hardware

[Spoon]

Re: dBpoweramp Music Converter R14 Discussions

Renaissance and R14 are not related in anyway.

[EliC]

Re: dBpoweramp Music Converter R14 Discussions

Renaissance and R14 are not related in anyway.

I was under the impression that renaissance would introduce some database functionality that would -maybe- be used to add more features to dMC. I guess I was wrong.

[Porcus]

Re: dBpoweramp Music Converter R14 Discussions

How is this multi-pressing AccurateRip functionality supposed to work? Is it checked with every possible offset at each stage where version 13 would normally invokes AccurateRip, or are the alternative offsets only used at the very end if the situation is so that version 13 would halt with Inaccurate [n]?

Also, from some experiments, it looks to me that if there is an Accurate [m] from one pressing, then accuracy = m regardless of whether offset shifting would have proved it to be identical-modulo-offset to another pressing?

Or do I need the cuesheet applied to use different pressings at all?

Last: Is there planned a "DSP" / utility codec to retroactively test CDs for being identical modulo offset?

[Spoon]

Re: dBpoweramp Music Converter R14 Discussions

>only used at the very end if the situation is so that version 13 would halt with Inaccurate [n]?

If normal checking fails then alternative pressings are checked.

If you view the log it would tell you if a different pressing was used.

There is no DSP effect planned.

[falconsoars]

Re: dBpoweramp Music Converter R14 Discussions

Thanks for this latest version of a great product!

Being in the midst of doing a lot of testing prior to ripping my entire 2500+ collection, I took the opportunity to run the 14.0 beta version against the 13.3 released version to see if I could detect any differences. I thought you might be interested in the results, given you're in beta testing mode.

Ripping speed was exactly the same for the test album I used - "Big Blue Ball" (an exceptional World Music 2008 compilation album produced and partially performed by Peter Gabriel and Karl Wallinger (of World Party)), regardless of CD Grabber version, settings, or drive used. All tests produced 100% accurate results, per AccurateRip (with reliability of 36-37 on each track) and when used, per C2 error detection.
~~~~~~~~~~~~~~
System Specs:

Computer:
Intel Core 2 Duo E6850 @ 3.00GHz, 1333 MHz FSB
Installed Physical Memory 4.00 GB
Total Physical Memory 3.24 GB
Total Virtual Memory 6.49 GB
OS: Microsoft Windows 7 Ultimate Version 6.1.7600 Build 7600

Optical drives (tried each test on each of these drives with no apparent differences):
- Pioneer DVR-115D
- Optiarc AD-7240S

Hard drives used for test (all internal SATA drives):

• CD Grabber ver. 14.0.0.0 ran on: WD Raptor 150GB 10K RPM 16 MB Buffer HDD
• Audio files ripped to: WD SE16 500GB 7200RPM 16 MB Buffer 3.0 GB/Sec OEM hard drive
• CD Grabber ver. 13.3.0.2 ran on: A differenti 500 GB 7200RPM 16 MB Buffer OEM hard drive

Note: I installed and ran the two versions on two different drives to help ensure I and the computer wouldn't get confused about which version I was running at any point.

All tests were done using the same multi-encoding formats I will be using to rip my collection:

• FLAC5 (my archival copy)
• ogg Vorbis aoTuV (SSE3) - VBR Q5 (to play on my Sansa Clip portable)
• m4a Nero (AAC) - VBR Q.5 (for my partner to play on her iPod + for me to play on Rhapsody, where, with the combination of my ripped files and my streaming library files, I will end up with a library of 120,000-125,000 tracks and over 500 playlists to play on Rhapsody. I will also have the same size library available to choose from for uploads to my 12 GB Sansa Clip, except I have to load the ogg files instead of the m4a's because it doesn't play aac format. Weird, in that it plays a bunch of others, more than many portable devices - MP3, WAV, WMA, secure WMA, FLAC, Ogg Vorbis, and audiobook)

All tests were performed in Secure Mode since that's all I rip in. I tested with C2 error detection on and off on each DVD drive with each version.

I tested the 14.0 beta version with Cross-Pressing Verification On and Off, again on each DVD drive.

All tests produced the same results:
Rip time for this 59:13 CD was 5:00 minutes plus or minus two seconds, with 100% accuracy for ALL tests.

So for my purposes, I'm going to start ripping my collection using the 14.0.0.0 beta version of dbpa Ripper.

In my younger days, I was a software systems architect and tester who was given the handle of "Crash Gordon" :teufel8: because I could crash any programmer's code, even if I did it with what I called "Monkey Testing" - trying things no normal person would try (but then how many "normal" people are there in the world any more). Regardless, this is an impressive beta version because I didn't come across a single bug (although my test was pretty narrow).

:smile2: So my congratulations and thanks for another quality dBpoweramp product!

~~~~

I don't know if this is the place to ask, but this has bothered me throughout my testing. The rip times shown on the information and error logs are completely different than what I experienced in clock time for the CD rip. On the logs, the rip times for this album have always totalled 2:10 plus or minus one second, not only in these tests, but in every other test I've ever done with this CD.

But the time it actually took to rip the CD has been totally different. For these mid-level quality settings, it's been around 5 minutes. Perhaps it's because the hardware has the power to handle the increased processing, but I've found that increasing the quality and/or the number of encoders for any given rip has minimal effect on the total rip time - less than 20 seconds difference. Of course, the file size varies considerably.

In any case, it's made my job of testing much harder to have to monitor the entire rip to make note of the total rip time off the ripper timer just as it finishes. I thought I could just add the times up on the log but that always comes out to 2:10 so it was useless for my testing.

Item for the wishlist: Include the actual clock total rip time on the log.

Another oddity I haven't been able to figure out: When I'm multi-encoding, I always check the multi CPU box because a Core Two Duo has two processors. Sometimes, the ripper will rip a track and start ripping the next track, while the other processor is encoding the ripped track. But other times, this is done sequentially with the ripping always followed by the encoding and no overlap or use of multiple processors. Is this something I can control? Will it affect total rip time? Or doesn't it matter, so I should just ignore it?

[Porcus]

Re: dBpoweramp Music Converter R14 Discussions

>only used at the very end if the situation is so that version 13 would halt with Inaccurate [n]?

If normal checking fails then alternative pressings are checked.

The following is rather a general consideration for checking AccurateRip with alternative pressings, but I'll put it here nevertheless:

http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=775&gopid=679963

Short: If I am right, then for one of the first CDs I tried here, the two pressings have different track boundaries.

[Spoon]

Re: dBpoweramp Music Converter R14 Discussions

The rip time is time to rip, not encode which is left to its own.

If hte CD drive is ripping 100% of the time then encoding is working correctly and you cannot speed it up.

[BugsBunny]

Re: dBpoweramp Music Converter R14 Discussions

Does this version support gap detection already?
If so I'd run some tests for sure...

[Spoon]

Re: dBpoweramp Music Converter R14 Discussions

Not currently.

[falconsoars]

Re: dBpoweramp Music Converter R14 Discussions

I'm not sure if this is a beta version issue but since it happened using the CD Ripper 14.0.0.0 beta version, I'll post my problem here. I am starting to rip my 2000+ album collection to FLAC/ogg vorbis/m4a or FLAC/ogg vorbis when the m4a for an album has already been ripped by my partner with iTunes. To make my workflow easier, I created 16 different profiles that cover the range of options I will be choosing between as I rip my CD's.

Example of an option - "Secure Rip or Ultra Secure Rip." I take meticulous care of my CD's so I rarely encounter problems with scratches, etc when ripping my CD's. But my partner takes terrible care of her CD's so most of them are in pretty rough shape with lots of ripping errors. I'm ripping my CD's in regular Secure mode with AccurateRip and C2 enabled. I'm ripping hers in Ultra Secure Mode so I have more control over how errors are handled. This one of 4 different options I'm using when ripping. Thus, with every possible combination of the four options, I have 16 total profiles to choose from for each album.

Problem: The CD Ripper is sometimes completely dropping all of the encoder settings for the individual codecs being ripped via the multi-encoder. These take me a long time to input, so this is major problem for me.

For example, all 16 multi-encoder profiles were working just fine on Wednesday, Jan 20, when I shut down for the night. But when I came back in on Thursday morning, every one of the individual encoders had been erased off of the multi-encoder profiles. The 16 profiles were still there along with the secure level settings, metadata, and other settings that cover all the encoders in that profile. But the the window to the right of the multi-encoder setting, where you add and specify each of the encoders to be used for that multi-encoder profile was completely blank for all 16 profiles.

So I spent yesterday trying to figure out what happened and finally today spent hours re-inputting all 16 profiles with 2-3 encoders for each profile.

Of course, I want to avoid having this happen again. So I tried to backup everything that might possibly have to do with Illustrate or dBpoweramp, including program files, apps data, and registry data, because I couldn't find any reference to where the profiles are stored.

My questions for you:
- Any idea what might have happened to erase all the encoder settings overnight, especially how I can prevent it from recurring?
- Where are the profiles stored, so I can back them up and restore them if this ever happens again?