problems with R13 and new Multi Encoder

[jbmccune]

I'm trying out the new Multi Encoder w/ R13 beta, and I ran into a few problems. I uninstalled everything, used the utility to wipe all trace of dBpoweramp, installed R12.4 Reference Trial from scratch, installed R13 overtop without uninstalling 12.4, installed the m4a codec, and installed the latest Multi-Encoder version from the beta forum.

1) Album Gain tags are still not being written to the files w/ the latest R13 and Multi-Encoder versions. The AccurateRip tags are being written now, but not the Album Gain.

2) After ripping one of my CDs, I got the following error:

Error ripping to [Multi Encoder], 'Track 5' to 'C:\Users\Jesse\Music\Leftfield\Leftfield - Leftism - 05 - Original.IGNORE'
   Error opening file, check no other program has it open.  [clDecoder::WriteIDTags]

First of all, that's not the correct path to the files - it should have been D:\Music_tmp\MP3\05 Original.MP3, which is in the folder that all of the MP3s are being ripped to. The MP3s are all there and everything looks good - the only thing that is missing is the AccurateRip tags on that one track, #5 - all of the other tracks, whether MP3 or ALAC in another folder, have them. I have no idea why the MP3 for that one track failed, but I ripped just that one track again and it worked fine.

It seems like the fix to write those missing tags has some problems. I hope this helps resolve them.

[Spoon]

Re: problems with R13 and new Multi Encoder

Do you have a virus checker?

[jbmccune]

Re: problems with R13 and new Multi Encoder

Do you have a virus checker?

Yes, Windows Live OneCare. You think maybe the scanner had the file locked, and the Multi Encoder therefore couldn't write to the file? I suppose that's possible. I'd prefer not to have to turn off my anti-virus every time I want to rip a CD. I think I read in one of the posts that there were ideas floating around about changing how this works altogether, so that Album Gain can be calculated for only the tracks from the same format, for example. I don't imagine that's a quick change though, so maybe in short-term the Multi Encoder could be changed to retry a few times before giving up?

Am I supposed to be getting the Album Gain tags now too, or have only the AccurateRip tags been added to the Multi Encoder so far?

I'm curious why the AccurateRip tags aren't being written with the rest of the tags - I know they aren't known until the track is completely ripped, but that happens before the encoding starts, so couldn't they still be added to the initial write of the file? Maybe you're writing the tags to the buffer along with the music data as it's being ripped, but I'm sure there are solutions to make it reasonable. Since the ID3v2.3 tags for MP3s are at the beginning of the file as far as I understand, the file would still have to be rewritten for the Album Gain tags, but for people who want the AccurateRip tags but don't care about the Album Gain, wouldn't that save a whole rewrite of each file? Not a big deal, but it seems like an efficiency gain.

I think ideally all of the tags would be written at the same time, but I understand that the Album Gain in particular makes that complicated. It doesn't make sense to read the whole CD just to calculate the Album Gain prior to ripping, and waiting to write any of the tags to any of the files until the whole CD is ripped risks leaving untagged files out there if the process is aborted somehow.

Maybe it could write the rest of the tags, including the AccurateRip tags, before moving on to the next track, but then still keep the file open until the CD is finished so that Album Gain can be written without having to worry about another process locking the file. That way if the process is aborted the file is released with only the Album Gain tags missing.

Or it could write the data to a file buffer, or to temporary raw files (the music data sans tags essentially), then build the actual MP3s, ALACs and what-not out of the buffer/files with all of the tags once the whole CD is finished. The benefit there is that you don't have untagged or partially tagged files if the process is aborted. This would really only be necessary for Album Gain though, and could potentially be less efficient or even frustrating in other situations. It seems like a lot of work for one feature, but it is a good feature.

Just my thoughts...maybe they're helpful.

[Spoon]

Re: problems with R13 and new Multi Encoder

Something had the file locked.

>but that happens before the encoding starts

Encoding starts before AccurateRip tags in burst mode.

>but then still keep the file open until the CD is finished

With Multi encoder it is about 5 processes away

CD Ripper (writes AccurateRip Tags) >> Core Converter >> Multi Encoder >> Core Converter >> Encoder

[jbmccune]

Re: problems with R13 and new Multi Encoder

Something had the file locked.

Sure, the error did say that, but not knowing how the processes are handled internally, I couldn't say that it wasn't one internal process blocking another - it is beta code after all. I think the virus scanner is very likely the culprit if you say that it isn't something internal. But I'm sure you agree that asking users to disable their virus scanners in order to rip CDs isn't a good idea.

Encoding starts before AccurateRip tags in burst mode.

Ahh...burst mode.... I don't use it, so I didn't think about it. That complicates things a bit. You're sure you don't want to write separate code paths optimized for each scenario - burst/secure, Album Gain on/off, AccurateRip used/not used, multi/single-encode, etc, etc?

With Multi encoder it is about 5 processes away

CD Ripper (writes AccurateRip Tags) >> Core Converter >> Multi Encoder >> Core Converter >> Encoder

I figured that. So implementing any of these ideas would require changes to the core components...not as simple as just passing the handle to the file around? I'd love to understand how the internals work more fully, but I understand if you don't want to share that. If I did understand it, I may or not be able to contribute to the design, but I would at least be less likely to make bad suggestions or ask dumb questions.

(Hey, this is like that awkward period of a project when the new guy comes in half-way through and starts asking questions and making suggestions that you've already been through and ruled out for various reasons.... Occassionally they're good ideas, but mostly they're just time-consuming exercises. I guess that happens pretty much continuously with forum-supported projects like this...weird.)

Well, if it was simple, I'm sure you would have solved it already. I'll leave you to it.

PS - I still like the buffer/raw file idea...as long as it generates the final files individually if Album Gain isn't turned on. I'm sure that wouldn't be too much work.

PSS - Seriously, PM me if you have any interest in adding an experienced software architect to the project. I'd love to contribute in any way that I can, for free of course. I can send you my resume if you want to see it.

[bhoar]

Re: problems with R13 and new Multi Encoder

Sure, the error did say that, but not knowing how the processes are handled internally, I couldn't say that it wasn't one internal process blocking another - it is beta code after all. I think the virus scanner is very likely the culprit if you say that it isn't something internal. But I'm sure you agree that asking users to disable their virus scanners in order to rip CDs isn't a good idea.

Actually, the correct approach is neither to disable antivirus software nor complicate a ripping tool to work around antivirus software bad behavior.

The correct approach is to identify the file types, executable and perhaps directories that the antivirus software is causing problems with and configuring the antivirus software to leave them out of the "real time" scanning, but keep them in the scheduled scanning.

-brendan

[jbmccune]

Re: problems with R13 and new Multi Encoder

The correct approach is to identify the file types, executable and perhaps directories that the antivirus software is causing problems with and configuring the antivirus software to leave them out of the "real time" scanning, but keep them in the scheduled scanning.

No, that's the "easy", let's-not-change-anything-if-we-don't-have-to solution. You think your average user is going to want to setup exceptions in their virus scanner, or even know how? Even for myself, I don't want to have to remember to setup the exceptions again if I get a new computer, or decide to move my files to another drive or path, etc. It's a fine work-around for the short-term, but not a solution.

I know you're just trying to support dBpoweramp (so am I), but IMHO the reason the average Joe, and especially Jane, is so frustrated with software today, and why they tend to use inferior solutions and not take advantage of all of the wonderful potential available to them, is exactly this type of work-around, not-my-problem thinking - all of these features are too complicated and difficult to setup and use. See my post here. Frankly, software like this is by nature either not fully-featured, only usable by power users, or very complicated to design and develop - there's no way around it.

It comes down to a high-level design decision - what is the software trying to be and for whom? If Spoon's only intention with dBpoweramp is to pack in the features so all of us power-users can duct tape and finagle them into some mostly-usable, semi-automated process, then fine. From what I've seen of the product and read on the forum, I don't think that's the case - I don't think he would have bothered with a lot of the work he's already put into it. I don't think suggestions for how it could be made easier to use and work more seamlessly are out of place, or bad design decisions, even if they are complicated to implement. If Spoon disagrees, he can tell me and I'll shut up and go away.