Questions on ID-Tag for Windows R17

[RDaneel2]

So, using dBpoweramp Reference [CD Ripper] on Windows 11... I have some questions about the "ID-Tag" that shows up as a tab in the Properties sheet of Windows Explorer:

-1) OK, this is on the "Audio Properties" tab - on my 2560x1440 display (with what used to be called "Large Fonts" scaling), not all of the tags show, i.e., this tab could benefit from a vertical scroll bar

0) I believe ID-Tag is also a dBpoweramp (or "illustrate"?) product?

1) Should I expect to be able to perform relatively simple editing of the file metadata [using ID-Tag], and on multiple files at once? My use case is after I finished ripping an album, I realized the album art was wrong (I hadn't been paying enough attention), and I wanted to replace it on the whole CD's set of ripped tracks... or am I supposed to purchase on of the other products (like PerfectTUNES) to do this?

2) If the above is not unreasonable, I have an anecdotal remark (NOT an official bug report): on R17.5 (or so) for Windows, I performed the above operation (selected ripped tracks 1-10) and had the ID-Tag tab replace the album art with a locally-sourced jpg... the result was that tracks 2-10 had the expected new album art, but track 1 was left with ONLY the metadata - the flac data was truncated!

I mention this problem largely to see if the author/dev of this functionality in dBpoweramp has seen the issue and already corrected it, given that it is two minor releases back... data loss is, of course, one of the Bad Things(tm) in software, and while I just re-ripped track 1 of the CD to restore my data, this could happen in circumstances that aren't as easily remedied (ripped CDs are in offsite storage, the CD the tracks came from was iffy and a re-rip might not work, etc).

I really hope this sounds familiar and that a fix has made its way into the code, as I am currently copying whole folders of rips back from the NAS to local storage, then performing the metadata edit(s), and then copying it all back to the NAS if things check out... a cumbersome process.

I should mention that I believe the ripped tracks were on a Windows file share pointing to my Synology NAS (I always rip directly to a RAM-drive, and then copy out to the NAS).

Finally, if I used the tools included with dBpoweramp Reference incorrectly, or I really should employ PerfectTUNES for operations like this, please let me know.

Thanks!

[garym]

Re: Questions on ID-Tag for Windows R17

0) I believe ID-Tag is also a dBpoweramp (or "illustrate"?) product?

yes

1) Should I expect to be able to perform relatively simple editing of the file metadata [using ID-Tag], and on multiple files at once? My use case is after I finished ripping an album, I realized the album art was wrong (I hadn't been paying enough attention), and I wanted to replace it on the whole CD's set of ripped tracks... or am I supposed to purchase on of the other products (like PerfectTUNES) to do this?

Yes, you can edit single or multiple tracks metadata and art from here.

2) If the above is not unreasonable, I have an anecdotal remark (NOT an official bug report): on R17.5 (or so) for Windows, I performed the above operation (selected ripped tracks 1-10) and had the ID-Tag tab replace the album art with a locally-sourced jpg... the result was that tracks 2-10 had the expected new album art, but track 1 was left with ONLY the metadata - the flac data was truncated!

I mention this problem largely to see if the author/dev of this functionality in dBpoweramp has seen the issue and already corrected it, given that it is two minor releases back... data loss is, of course, one of the Bad Things(tm) in software, and while I just re-ripped track 1 of the CD to restore my data, this could happen in circumstances that aren't as easily remedied (ripped CDs are in offsite storage, the CD the tracks came from was iffy and a re-rip might not work, etc).

as a User, I've never seen this in the 9,000 disks I've ripped, converted, edited, etc. So I have no experience with this problem, if it is a bug.

[RDaneel2]

Re: Questions on ID-Tag for Windows R17

Thanks, garym, your numbers are impressive and I feel somewhat safer now - I even performed a number of "mass" album art replacements with less concern (and no mishaps).

I would feel a bit better if this had been tied to an actual code change, as I may still wonder when this could bite me again, given that it actually did happen once.

But hey, I am sure there have been quite a number of commits since then, and maybe it was "fixed" as part of one or more of those... and whenever I feel worried, I can always just keep on copying the whole track set I am modifying to my RAM-drive as a precaution.

[garym]

Re: Questions on ID-Tag for Windows R17

Thanks, garym, your numbers are impressive and I feel somewhat safer now - I even performed a number of "mass" album art replacements with less concern (and no mishaps).

I would feel a bit better if this had been tied to an actual code change, as I may still wonder when this could bite me again, given that it actually did happen once.

But hey, I am sure there have been quite a number of commits since then, and maybe it was "fixed" as part of one or more of those... and whenever I feel worried, I can always just keep on copying the whole track set I am modifying to my RAM-drive as a precaution.

I haven't seen this issue in 15 years of use. But in any case, after you've made a bunch of edits, my advice is to do a "Batch Convert" on your library (or at least the portion you've worked on), and "convert to" TEST CONVERSION. If these are FLAC files (that have built in checksums), the test conversion will decode the FLAC file, calculate the checksum for the audio portion of the file, then compare this checksum to the one that was created and embedded in the header when the FLAC file was created. If no errors occur when you run this, this means that your FLAC files are exactly the same audio content as when created and you can be sure nothing has changed. I do this occasionally on my entire library (takes about a day to run) to make sure I don't have any corrupted files.

[schmidj]

Re: Questions on ID-Tag for Windows R17

One thing I'd most strongly recommend, before doing any kind of a batch process that you back up your files to removable media. And even without doing batch processes do routine backups from time to time. The pre-batch backups should best be saved forever. Storage is cheap these days. It is very easy to mess up a batch process in some way that isn't apparent until months or even years later. And disasters like server failures, or even fires or theft are more common than you might think. Without a copy of the data before the batch run, you have a difficult or impossible recovery.

And if you back up to your typical "brick" USB drive, (or any "mechanical" drive, you need to plug them in and let them spin up from time to time. If you don't, the drive bearings may freeze and the drive fail to spin up when you need it. People with more expertise in drive reliability will have to tell you how long you can safely leave them alone, but as a starting point, consider spinning them up and verifying the data at six month intervals.

In my case, I originally ripped part of my collection to m4a to use in an Ipod, using Winamp. It only took a few weeks for me to discover that I had some bad rips. And I was careless with metadata. But about that time I also decided I wanted to play the files at home as well, and decided to rip everything to FLAC using dBpa to catch the bad rips when they occurred. When I reripped a CD to FLAC, I erased the m4a rip. But before I started that, I made a backup of the m4a rips, which I kept intact without deleting anything. And it has turned out that I was wise to do that, because on several occasions, I accidentally erased the wrong m4a file. And to make matters worse, when I discovered I had erased the wrong file and went to re-rip the CD I found in a couple of cases the CD had a disc-rot problem and couldn't be ripped any more. Now, obviously I'd like to have a FLAC rip, but an m4a is far better than no rip, and I was able to recover the m4a rip from my backup.

Better safe than sorry...

[RDaneel2]

Re: Questions on ID-Tag for Windows R17

Thanks for both of the sets of thoughtful advice... besides the current question of covering yourself when working on potentially hard-to-replace data, it sort of ties in to my larger concern of "how does one actually back up NAS contents, particularly when just the music portion is in the 100s of GB?"

Regarding the specific comments on "TEST CONVERSION", I haven't so far located that functionality in my Windows R17 - is this some sort of Mac-only feature, or have I just not looked hard enough?

[garym]

Re: Questions on ID-Tag for Windows R17

no it's in windows. After you select some files, right click, select "dbpoweramp BATCH CONVERT", then it will open up a window that looks like below picture. for the "encoder" in the dropdown box select TEST CONVERSION.

https://imgur.com/a/W3q1RVg

[RDaneel2]

Re: Questions on ID-Tag for Windows R17

Ahhh... so, I didn't have enough of the context-menu handlers specific to dBpoweramp enabled - and then there is the slight matter of the of slightly non-intuitive interface.

If you are already in the "Batch Converter" (however you got there), and you don't see anything to control / select options for the upcoming "conversion", you might not be inclined to click the button labeled "Convert"! Just sayin'.

In any case, thanks, this looks like a very workable way to test for gross corruption in music files - now if only the slick code using all 20 of my "cores" wasn't stuck with the rather sad 1 Gb/s LAN speed.

[garym]

Re: Questions on ID-Tag for Windows R17

Ahhh... so, I didn't have enough of the context-menu handlers specific to dBpoweramp enabled - and then there is the slight matter of the of slightly non-intuitive interface.

If you are already in the "Batch Converter" (however you got there), and you don't see anything to control / select options for the upcoming "conversion", you might not be inclined to click the button labeled "Convert"! Just sayin'.

In any case, thanks, this looks like a very workable way to test for gross corruption in music files - now if only the slick code using all 20 of my "cores" wasn't stuck with the rather sad 1 Gb/s LAN speed.

Yep, years ago, the first time I needed to select the CONVERT button, I was also unsure what was going to happen after selecting. I was happy to see that this led me just more options that I could easily control.

[RDaneel2]

Re: Questions on ID-Tag for Windows R17

Makes sense... or it would if I had some package that included flac actually installed on my NAS.

It is a cute little thing made for SSDs only with a small Intel dual-core processor and 2GB of memory, and while I have done some things locally through an SSH session and a command prompt, I would lose all the coolness of the parallel operation across the [woo hoo] 2 cores (well, unless the flac app accepts multiple files and tries to go for parallel processing on its own)!

[RDaneel2]

Re: Questions on ID-Tag for Windows R17

Wow, it's like a trip down memory lane to UNIX V7...

Thanks for the detailed recipe for the parallel execution of this FLAC "test" for corruption - but let's keep in sight the reason we got on the subject: making sure that a "mass" edit of audio file metadata (like album art) didn't corrupt anything, so we aren't really concerned with random filesystem rot. Actually, the dBpoweramp Batch Converter approach is fine, and I was only making half-serious complaints about the speed over what used to be a "fast LAN".

My NAS is one of the few SSD-only models I could find, a Synology DS620slim, using the Btrfs filesystem spread across 3 2-TB SSDs (and a 4th one as a spare for reconstruction). But I made sure it uses a "real" CPU (Intel architecture) with multiple cores, which does enable just about anything to be run within the constraints of 2 GB of RAM (a lot of us wish they had used a quad-core, but oh well). Note that it has 2 1Gbe ports and supports "bonding" them, and my main PC's mobo has a 10Gbe LAN... so I could double the NAS bandwidth to ~220 MB/s if I wanted to acquire a new local router.

As much as I really appreciate the amazing amount of assistance I have been offered here, the phrase "off-topic" keeps whispering in my ear... thanks again, all!