dBpoweramp R14.4 BETA

[mville]

mville: lets find out what is happening with flac first, take a FLAC file with has no ID Tags, (or an existing tagged file and delete the tags), then right click on the FLAC File >> Edit ID Tag

Add ComposerSort and give it a value: comp1; comp2

then look at the file in notepad, what does it show please?

ComposerSort=comp1
ComposerSort=comp2

Looks like the problem is related to CDRipper.

[mville]

Just found the probable cause.

When in CDRipper, ComposerSort tag added manually, then ripped to flac, tag is OK.

e.g. comp1; comp2 is written as:

ComposerSort=comp1
ComposerSort=comp2

When tags are obtained from dbPoweramp Cache (CDRipperCache.bin), then ripped to flac, ComposerSort tag is written as:

ComposerSort=comp1; comp2

i.e. not multi-value.

(edit: This behaviour also occurs for Artist Sort and Album Artist Sort)

[smisk]

bug: in configuration program, if you press button to check for updates, older (nonbeta)versions are displayed as the latest, while in fact what i have installed is newer.
Also, this dialog is non-resizable (which is ok) but the strings for reporting versions are too long for most of the modules. So either make window resizable or scrollable.
(replace "release" with "r" in all strings?)

[Spoon]

>bug: in configuration program, if you press button to check for updates, older
> (nonbeta)versions are displayed as the latest, while in fact what i have installed is newer.

This is by design, the main release is the latest release.

[mville]

When tags are obtained from dbPoweramp Cache (CDRipperCache.bin), then ripped to flac, ComposerSort tag is written as:

ComposerSort=comp1; comp2

i.e. not multi-value.

(edit: This behaviour also occurs for Artist Sort and Album Artist Sort)

Will there be a fix for this issue in the next beta release?

[Spoon]

I would hope so yes.

[BugReport]

Hello, I have been experiencing this problem with both the 14.3 release, and now the 14.4 beta:

I have an album which has tracks on it from a number of different artists, and I want them to all be stored in a folder under the Album Artist name, but not as a "compilation".

Using the "convert to" context menu option and Arrange Audio selected, I have the arrangement set as:

[IFVALUE][album artist],[album artist],[artist][]\[album]\[IFMULTI][disc][][track] - [title]

Which, if I understand things correctly should move everything into a folder with the name of the Album Artist, if that tag exists on the files (it does, and they all match) or move them into a folder with the Artist name, if that tag doesn't exist.

This seemed to work fine when ripping discs, but seems to be getting ignored when using Arrange Audio, and my tracks are all getting split up into folders which only have one or two tracks under the Artist's name, rather than using the Album Artist tag.


I also have the ReplayGain DSP Effect added, with the Write Track Gain, Write Album Gain (all files in batch same album) and Write iTunNorm Tag for iTunes option enabled. None of the files I run through the converter are getting ReplayGain tags attached, I'm only getting ReplayGain tags when I rip a new disc. I do not have the EBU R128 option enabled, as that actually edits the track to change the volume, rather than applying tags.

I've tried changing the "drop replaygain id tags" option, and that hasn't helped.


EDIT: When using the converter, either strifvalue and strnovalue are reversed, or it's not detecting the album artist tags and using the strnovalue instead.

[IFVALUE][album artist],[artist],[album artist][]\[album]\[IFMULTI][disc][][track] - [title]

Seems to work as I intended.

When ripping discs with different artists, it seemed to work correctly with [artist] and [album artist] the right way around, but I would have to check that to be sure.

[Spoon]

[IFVALUE]album artist,[album artist],[artist][]\[album]\[IFMULTI][disc][][track] - [title]

Is correct

It is not possible to use DSP effects with Arrange Audio, only by reconverting the files (FLAC >> FLAC), or use the [ReplayGain] utility codec.

[BugReport]

[IFVALUE]album artist,[album artist],[artist][]\[album]\[IFMULTI][disc][][track] - [title]

Is correct

Thanks, looks like I was putting in some square brackets that were not necessary.

It is not possible to use DSP effects with Arrange Audio, only by reconverting the files (FLAC >> FLAC), or use the [ReplayGain] utility codec.

Unfortunately the files I wanted to ReplayGain aren't FLAC (DRM-free music purchased via iTunes) but I was not aware of the [ReplayGain] utility codec, which should do what I need.

[thexfile]

Anybody having problems with the CD tray not returning when using the Eject button in dBp beta?

[dBprulez]

Should the Accurate Rip (AR) signature as calculated by dbpoweramp's cd ripper (R14.4 beta) be the same as the one calculated by the 'calculate audio CRC' codec and by XLD (mac, latest version) ?? Today I ripped a cd with some errors (and no Accurate Rip verification possible), but 11 tracks ripped with no errors, and both dbpoweramp's cd ripper and XLD reported the same CRC32's, but different AR signatures. I don't know if that's possible, the same CRC32 but a different AR signature, but I tested another cd and this time dbpoweramp's cd ripper and XLD reported the same CRC32's and the same AR signatures.

After a lot of experimenting and googling I noticed that for tracks ripped by dbpoweramp itself, dbpoweramp's 'calculate audio CRC' codec reports a different AR signature than dbpoweramp's cd ripper did (for the same dbpoweramp-ripped file !), however the 'calculate audio CRC' codec calculates the same CRC32's and AR signatures (for the dbpoweramp-ripped files) as XLD did for the XLD-ripped files. Seems a bit strange to me, dbpoweramp's cd ripper and 'calculate audio CRC' codec disagreeing on the AR signature, but I guess the 11 tracks are securely ripped, ripped on 2 different drives and XLD and the 'calculate audio CRC' codec agreeing on the CRC32's and AR signatures. I guess the problem is related to the cd, all the other cd's I ripped so far showed no problems and no one else seems to have this problem (?).

[Spoon]

No AccurateRips CRC is different than CRC32.

[dBprulez]

I know, but the question is why dbpoweramp's cd ripper and the 'calculate audio CRC' codec return different AR signatures for the same file ?? I.e. when I rip a track (to alac) dbpoweramp returns an AR signature, but the 'calculate audio CRC' codec then returns a different AR signature for the alac-file. And when XLD rips the same track to alac, it returns the same AR signature as the 'calculate audio CRC' codec... So the problem is the AR signature (there's no problem with the CRC32, all 3 tools report the same CRC32).

[Spoon]

>calculate audio CRC

This returns a CRC32

>dbpoweramp's cd ripper

This returns an AccurateRip CRC

XLD must be showing a CRC32, not AccurateRip CRC (if it matches Calculate Audio CRC)

[Spoon]

Update 17th January 2013

bug fix: [IF!EQUALS] was not working correctly
bug fix: wave id3 tagging fix (where could write an extra byte to the end of the file, giving a warning on wave decode)
bug fix: converting wave (LIST + id3 tagged file) >> wave would only write (id3 tag)
bug fix: m4a tag writer was inefficient when trying to trim a huge tag (image as base64, for example) down to the allowed 255 chars
bug fix: a badly corrupted FLAC file could cause the converter to terminate encode based on timeout, not reported errors
bug fix: cd ripper - if reading ISRC and was not present for a track, then track+1 would not have ISRC read either
bug fix: cd ripper, batch converter, would default their positions if moved to a certain display (on multi monitor systems)

This is now a release candidate, hopefully a full release within 4 weeks.