dBpoweramp R15.2 Discussions

[Spoon]

Re: dBpoweramp R15.2 Discussions

<now released>

[jsmulree]

Re: dBpoweramp R15.2 Discussions

ISRC could be coming from AMG or MusicBrainz, you would have to disable these to be certain it comes from the CD its self (if you have the ISRC option enabled).

Hello Spoon,

Thank you for replying.

The only source I use for ISRC is the disc itself - I always delete the ISRC tags and then and manually read these values from the disc (automatically reading these values from the disc can cause issue when the same information is provided by other metadata sources). As a side: Any existing ISRC tags must be deleted before attempting to manually read these values from the disc otherwise nothing happens, and to delete the ISRC values for all tracks at once, I cannot simply delete the ISRC tag as the tag is only listed if a single track is selected (this did not occur with previous versions), instead I have to create an ISRC tag (with no track selected) then delete it.

For testing I disabled all metadata lookup and then deleted the cache, then repeated the testing - same results. Interestingly, the 'mediatools' program, although it consistently and accurately reads the correct ISRC values from most discs, for some discs it fails to read any ISRC values (though never returns incorrect ISRC values) and often dBpoweramp accurately reads the ISRC values for these discs. This leads me to thinking that several methods are used for storing ISRC information on the discs and therefore complicating the situation.

Cheers,

Jason.

[Spoon]

Re: dBpoweramp R15.2 Discussions

ISRC could be coming from AMG or MusicBrainz, you would have to disable these to be certain it comes from the CD its self (if you have the ISRC option enabled).

[jsmulree]

Re: dBpoweramp R15.2 Discussions

Greetings Spoon,

I have noticed some inconsistencies when reading ISRC information from a disc. Often ISRC information is duplicated for consecutive tracks and deleting the ISRC tag and attempting to re-read the ISRC information for the disc will yield a different ISRC - sometimes this appears to be the correct ISRC, while other times it is a duplicate of the previous or following track.

I have conducted some extensive testing and discovered that the issue affects version 15.1 also though I am raising the issue in this thread as it affects version 15.2 also. I have used different discs and drives on different controllers and even external drives and have encountered the same issue, though interestingly the issue does not occur using my internal LITEON drive. I tried EAC and had similar results though I unsure if there might be some common code used?

I have tried a program called 'mediatools' (http://www.flanagan-family.com/mediatools.zip') which I discovered by reading a post on your forums from 2008 regarding inconsistencies reading ISRC information from discs ('https://forum.dbpoweramp.com/showthr...stancies/page2') and this appears to consistently and accurately read the correct ISRC information (as confirmed via a disc with sequential ISRC values).

Interestingly, when using my internal LITEON drive, reading the ISRC information occurs much slower compared with using any other drive. When using the 'mediatools' software, reading the ISRC information from ANY drive is also much slower though appears consistent and accurate. I have no idea if or how this is relevant, however it forms part of my observations during testing so I have mentioned it.

Regards,

Jason.

[111MilesToGo]

Re: dBpoweramp R15.2 Discussions

If you have ID Tags you would set as:

C:\Users\MyUserName\MusicArc\mp3fromflac\[artist]\[album]\

Yes, would be the easiest, but doesn't fit my needs. In some cases, the album title in the tag would differ from the album title in the storage path in order to not exceed the 255 characters in a pathname.

My main reason to ask for a REPLACEFOLDER function is: I have several music archives on several hard disks, as I guess many peple have. For each HD, the front portions of the path would differ, such that e.g. the \FLAC node in the path is at different character positions and different node depths.

Thus I am looking for a generel naming rule in dBpa Music Converter which would be valid for all my various structures of origpath, without the need to edit it every time I am running Converter on a music archive on another hard disk.

I hope this explains my asking for REPLACEFOLDER function better. And I hope that my reference to such naming function being useful for many peope will make you consider it.

Thanks!

[Spoon]

Re: dBpoweramp R15.2 Discussions

It would not do, the cache stores metadata, track number is not created until Rip is clicked, and the offset applied then.

[thexfile]

Re: dBpoweramp R15.2 Discussions

I'm using dBpoweramp R15.2 (64bit) Update 21st January.

The Cache isn't saving any track offset information.

[Spoon]

Re: dBpoweramp R15.2 Discussions

If you have ID Tags you would set as:

C:\Users\MyUserName\MusicArc\mp3fromflac\[artist]\[album]\

[111MilesToGo]

Re: dBpoweramp R15.2 Discussions

dBpa Music Converter: Question and suggestion regarding the functions for pathname handling

A question regarding computed ("dynamic") building of output path and filename in Music Converter: Within the path string, which looks like (Windows 7)
C:\Users\MyUserName\MusicArc\FLAC\artistname\discn ame\,
I just want to replace the \FLAC\ node in the tree with something like \MP3fromFLAC\ to create a whole new branch underneath \MusicArc. I was missing a real REPLACE function in Music Converter's naming handling to be applied to originalpath. Or did I overlook it? I could use nested TRIMFIRSTFOLDERs or nested GRABs.

But a true REPLACE-like function would be easier to use and would be fully portable between machines, i.e. not requiring a counting of characters or of folder level on origpath. It could be like
[REPLACEFOLDER]FolderOld,FolderNew[origpath][],
which to me would look best and be in close analogy to your TRIMFIRST/LASTFOLDER functions.

For example, I could then just handle my output path by something simple like
[REPLACEFOLDER]FLAC,MP3fromFLAC[origpath][].

I hope this suggestion makes sense and could be implemented in R15.2 of dBpa Music Converter. Otherwise, suggestions for handling this replacing of one node in a path with another one using the current dynamic naming functions in Music Converter are very welcome.

[111MilesToGo]

Re: dBpoweramp R15.2 Discussions

dBpa CD Ripper not updating filenames with track numbers when applying track number offset


My file naming rule in CD Ripper puts track numbers into the filenames. When applying a track number offset (right click), the track numbers themselves (first column in CD Ripper's default view) do change immediately, but the filenames built are not being refreshed as I would have expected. Hitting Enter on the track title does not suffice, it takes editing a track title to some dummy text and entering that to make all filenames reflect the new track numbers; thereafter, this edited track title needs to be reverted. I guess it would be a good idea to refresh filenames based on the naming rule right away when applying a track number offset.

I hope this suggestion can still be implemented in R15.2 of dBpa CD Ripper.

[Porcus]

Re: dBpoweramp R15.2 Discussions

Forgot a couple of things:

There should be a strange immediate abort in the logs when I switched CD, as I mis-hit the Rip rather than the Refresh button and then aborted ASAP.

And:

managed to provoke forth

[...]

I should say that while fb2k and the web browser took their 200 megs of memory, CDgrab.exe didn't take more than a few.

Should also add: "managed to provoke forth" means that I did run this with an XP that had been up for a couple of days, which was low on resources, and managed to get the error. (Straight away though.)
Did a reboot and installed 15.2 again (atop 15.1 this time for laziness) and run it, then the error was gone.

[Porcus]

Re: dBpoweramp R15.2 Discussions

however as a test in R15.2 beta, disable the gap and index detection.

The error where no audio is written, it is because CD Ripper is out of memory, why this is happening I am not sure.

I will pm you a sendspace link in a minute. I packed away the changer (done with ripping, soon Xmas, takes a bit of a rig including the mains transformer ... don't mind wearing out the U2 though, it stinks), but:

I managed to provoke forth similar-looking errors with the internal drive. Well even worse errors.

What I did, was

0) dBpoweramp was already uninstalled it seems, but not using the utility to wipe entirely.

1) Install 15.2 beta 3 . (Disabling Avast for ten minutes after it reporting the install-exe as malicious, sent them a false-positive report.)

2) Try to rip a CD. Track 1 almost immediately jumps to encoding which is stuck at zero - then track 2 does the same.

3) Repeat step 2 a few times with a different CD (the U2), trying various things: to cancel gap/detection or not, to rip to WAV in place of FLAC, and to rip to Test Conversion. Same result.

I should say that while fb2k and the web browser took their 200 megs of memory, CDgrab.exe didn't take more than a few.

4) Install 15.1 again.

5) Rip the U2 to test conversion. Good!

6) Rip the other CD to FLAC. Good!

OS: Still XP. I'd still say it is a fairly fresh reinstall (made just when MS discontinued support, but it is hardly used for anything but music management).

[Spoon]

Re: dBpoweramp R15.2 Discussions

I recheck the source code for R15.1 and R15.2 the only difference is the index and gap detection code (and TOC processing), we can rule out the TOC processing as it is ripping from and to the same lba, however as a test in R15.2 beta, disable the gap and index detection.

The error where no audio is written, it is because CD Ripper is out of memory, why this is happening I am not sure.

[Porcus]

Re: dBpoweramp R15.2 Discussions

From the logs:


[...]


So C2 is used in R15.1 and works, but not in R15.2, and R15.2 does not work...

I forgot to highlight what I did here, sorry. Will explain.


But first: no, it does not work in 15.1. Go one step further down in the 15.1 log, the 11:10 rip. You will see that it has to re-rip frames in tracks 3 5 6 7 8.
That only happens when C2 is enabled on this (and most) discs in the AccurateRip database. With C2 off - or with other drives, C2 on or off - a burst rip verifies against AR and that is it. With C2 enabled on the Sony, most tracks have to run the full Ultra-Secure routine and re-rip a few frames.

According to the flowchart at http://www.dbpoweramp.com/secure-ripper.htm , dBpoweramp is supposed to accept a burst pass which verifies with AR. Ergo, enabling C2 on the Sony alters the burst pass output.


Then to confess my sins: somewhere in the workflow I switched to accept C2 in order to get that thing debug-logged too - for the Equinox disc (item 2.2.3), I intended to keep the U2 out of it, but I forgot to revert so that was done only midway with the 15.1 rips (item 3.2.3); once I had ripped U2 with 15.1 and - from the mere fact that it re-ripped frames - recalled what had happened, I performed burst passes to see the difference.
And I forgot to highlight it as well, so it is not mentioned in the about&before&after.txt roundup - mea culpa. But see the individual reports I wrote, the items cited.

[Spoon]

Re: dBpoweramp R15.2 Discussions

From the logs:

dBpoweramp Release 15.2 BETA Digital Audio Extraction Log from 14. desember 2014 07:44

Drive & Settings
----------------

Ripping with drive 'P: [MATSHITA - DVD-RAM SW-9584 ]', Drive offset: 102, Overread Lead-in/out: No
AccurateRip: Active, Using C2: No, Cache: 1024 KB, FUA Cache Invalidate: No




dBpoweramp Release 15.1 Digital Audio Extraction Log from 14. desember 2014 11:04

Drive & Settings
----------------

Ripping with drive 'P: [MATSHITA - DVD-RAM SW-9584 ]', Drive offset: 102, Overread Lead-in/out: No
AccurateRip: Active, Using C2: Yes, Cache: 1024 KB, FUA Cache Invalidate: No




So C2 is used in R15.1 and works, but not in R15.2, and R15.2 does not work...