dBpoweramp R15.2 Discussions

[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.

[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.

[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.

[Spoon]

Re: dBpoweramp R15.2 Discussions

If you have ID Tags you would set as:

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

[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

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

[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!

[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.

[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

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

<now released>