Ripping error, short tracks

[schmidj]

In ripping a sound effects CD with a number of short tracks, I randomly get an error message:
Error ripping to [Multi Encoder], 'Track 7' to 'C:\Users\John\Music\DBpoweramp test\None\Video Helper Sound Effects Library; Sound Design Elements\07 None - Intermission.IGNORE'
m4a FDK (AAC): Error: Copying Temporary Rendered Live-DSP file, over Temp Non-Live DSP file, disk full?. [dBCoreConverter::HandleNonLiveDSPs]

The CD is not in accurate rip, for non-accurate rip I'm using a secure rip, two full speed rips followed by (if no ripping errors) at least one vari-speed ultra secure rip.

Track 7 is 26 seconds long

CD drive I was using was via USB-SATA converter, so reripped in different CD drive, direct SATA, track 7 read OK, but got the same error message on track 20 (35 seconds long). Obviously the filename was different. Tried again, got the error on track 7 but not 20. Tried once more, all tracks ripped successfully.

Drive C is a solid state 476 GB drive, 357 GB free.

Multi encoder is FLAC then m4a FDK (AAC)

Windows 7, 64 bit, fast machine with loads of RAM

dBpoweramp is registered reference 15.2, 64 bit. DSP release 11

DSP effects in FLAC: Replay Gain, Delete Destination file on error, bit depth, Audio CD Silence Track, Trim Silence, Audio CD Hidden Track, HDCD, Playlist Writer

DSP Effects for m4a: Delete Destination File on Error, Bit Depth, Playlist Writer, Replay Gain, Trim Silence, Audio CD Hidden Track, Audio CD Silence Track.

The two encoders point to different directories on a very large raid QNAP NAS box, using dynamic naming strings.

The files were not saved when I got the error, but the rips were reported as secure.

I think I recall seeing this rarely before.

Any ideas?

[Spoon]

Re: Ripping error, short tracks

Try ripping to your local hdd to see if the errors go away.

[schmidj]

Re: Ripping error, short tracks

Hello Spoon,

Changed FLAC and m4a naming strings to almost empty d: (raid sata hard drive array) local drive, temporary storage was already on c: drive, a local SSD.

Got an error message on track 20 this time:

Error ripping to [Multi Encoder], 'Track 20' to 'C:\Users\John\Music\DBpoweramp test\None\Video Helper Sound Effects Library; Sound Design Elements\20 None - Dead White Guys.IGNORE'
FLAC: Error: Copying Temporary Rendered Live-DSP file, over Temp Non-Live DSP file, disk full?. [dBCoreConverter::HandleNonLiveDSPs]


Any ideas?

Thanks,

John

[Spoon]

Re: Ripping error, short tracks

If you type %tmp% into Windows explorer, this drive has plenty of free space? (over 1GB)? Try a disk check on this drive also.

Also which security software are you running?

[schmidj]

Re: Ripping error, short tracks

Sorry for the slow reply, I've been otherwise occupied.

%tmp% points to the "c" drive, a SSD with 359 GB free. Interesting that there are many ripper rip reports in there that were never deleted. I have the ripper save a copy of the rip report in the folder with the rip, which it does.

Ran the windows disc checker three times without any errors being found.

I'm running Mcaffee Multi-access, and I have had a recent issue where it messed up Adobe Photoshop and Lightroom, kept blocking access to the registration and update link. So I'll try the rip with McAffee shut off when I have a moment. Certainly a possibility.

Thanks

[schmidj]

Re: Ripping error, short tracks

So McAffee's firewall appears, so far, to be the culprit. Turned off the firewall and real time scanning. Ripped twice without errors. Turned on real time scanning, ripped once without error. Turned firewall back on, got error on 26 second track on first rip attempt. Now three successful passes with the router off is not completely conclusive, as the errors don't happen all the time, just most of the time, but the evidence certainly is pointing at the firewall.

The error comes after all three rip passes (the CD is not in Accurate Rip), after it says "encoding" for a short period of time.

I'm a little puzzled, AFAIK, there should be no Internet access, or even Ethernet access, I'm saving to the local "C" drive. The CD is not in Accuraterip, and says so, I would assume that query is long over at ripping time.

I looked in the settings for the firewall. There are a number of entries for Illustrate software. For instance the entry for dBpoweramp when examined points to cdgrab.exe, access is set to incoming and outgoing, use designated ports (recommended). Other choices are "open ports to work and home networks" and "open to all devices". What they call "net guard" is turned on, choices are on or off.

Any suggestions as to what executables need entries, and what settings you recommend? I could experiment more, but if you have recommended settings, I'd try them first.

Thanks.

[Spoon]

Re: Ripping error, short tracks

Coreconverter.exe

However this has zero internet access.

[schmidj]

Re: Ripping error, short tracks

Some further testing discloses I may have spoken too soon, the problem is somewhat spasmodic, and now seems to be related to the "real time scanning", not the firewall.

I need to do some more testing, I think I'll make a CD to rip with a bunch of 15 second tracks.

McAffee's real time scanning has no apparent way to exclude directories from the real time scan, only files. It does have an option to only scan programs and documents. When I tried a chat session with McAffee support, I ran into Support India hell..., then looked at their forum and a search disclosed a similar complaint a year ago, with the real time scanning breaking a program using files in the "tmp" directory, again program unable to access the files sometimes. Complaint apparently unresolved.

I won't have a chance to play with this again until early next week, I'll update then. However I surmise that the real time scan locks the file while reading and scanning momentarily at the same time DBPA is attempting to write to it with the new updated version (possibly after applying the DSP?), its an issue with short rips because the DBPA processing time is less and the scan hasn't finished looking at the new "tmp" file. Note the temporary file is stored on a SSD with very quick access, this may make the issue worse?

Any thoughts?

[Spoon]

Re: Ripping error, short tracks

Temporary files are private to applications, and no application expects another program to jump in and lock them.

I think the temp files could be .bin, you could exclude this entire file type as no .bin files have virus anyhow (they cannot run and do not open with any programs).

[schmidj]

Re: Ripping error, short tracks

I had time finally to investigate this more thoroughly and the result is confirmed: McAffee's real time virus (and other malware) scanner is the culprit.

First, I was at my brother's home last weekend, and took my laptop to rip some of his CD collection to add to mine. (yes, I know I'm now probably a lawbreaker, I don't own a copy of the CD's I ripped, but I'll call it fair use, he's my brother...) Anyway, I got the same error on a short cut on one of his CD's. Different computer, different disc drive, different speed CPU, both Windows 7 64 bit, both McAffee Antivirus, both current ripper, both solid state "C" drives, but different sizes and manufacturers. Turned off the real time scan, it ripped fine.

So today, I made a CD 15 second and 60 second tracks (tone) somewhat randomly intermixed, 25 total tracks. Ripped it (real time scanning, etc on) got one error. Actually, the tracks were each 4 seconds longer, as I forget to set the "pause" silence between tracks in the CD burner software to zero. So I made another CD, this time 40 10 second tracks, this time with no "pause" between tracks. That one ripped without error. Hmmm... That's strange. Possibly the real time scanner ignores short files?? So I made a third CD, Thirty 30 second tracks, again, no "pause". This time I hit pay dirt. 7 out of the thirty ripped as "error". Tried again, this time just ripping the odd number tracks wondering if the longer seek time on the CD drive would change anything. 6 errors out of 15.

Turned the real time virus scan off, ripped the CD three times without error. Turned it back on, 5 bad out of 30. Then changed the real time scan setting from the default and recommended "scan all files" to only scan "programs and documents" Ran the ripper on the CD twice without error.

I did notice something strange. The CD was 30 copies of the same audio file, 30 seconds of 400 Hz tone at -12 dBFS. Yet all the CRC's were different for the tracks. The same for the same track on each rip, but different from track to track on what was presumably identical audio. Scratched my head over that, and looked at the settings on the CD burning software (Sony's CD Architect). Realized that the dither plugin was turned on (you can feed it 24 bit files, etc, it dithers to 16 bit dithered. Also had the "automatic crossfade" turned on (why??? I don't want that on anyway!) Turned them off and recorded another disc. This time all the CRC's were the same, except for some reason, the last track. Why??? (the pause time is zero, so the tracks should be the same length??? (If there is pause on a CD, dBPoweramp appends it to the preceding track). Also got no errors with this rip.

Now there are very limited exclusions on the real time scan. You can exclude particular files, (not practical for temporary files, they don't even exist when you are setting up the scan exclusions!) You can't exclude directories or file types. There has been more than a little grumbling about this on the McAffee forum, apparently, much older versions had this option, but for several years it has been missing.

So, therefore, I have now set McAffee's real time scanning to only scan "programs and documents". This might want to be added to the FAQ file on antivirus misadventures. Also anyone else here using McAfee might want to look at their settings.

What bothers me is that I remember seeing this error before, but when I reinserted the CD to re-rip, it said all tracks were secure, which they were, just they never made it to the requisite hard drive. And I never actually looked at the stored files, since it now said "secure" I thought it was a fluke and went on to ripping the next CD... Now I should really look through the several thousand CD's I've ripped (to both FLAC and m4a, the errors appear to be equally split between them) to look for missing tracks. Grrr.

Spoon, although this isn't the fault of the ripper, you might want to consider changing the error action on "unable to open file to write" from an immediate error to wait some number of milliseconds and try a second time, if still unable to write, then error. This would also probably help with issues of slow response from networked NAS drives, USB stick or hard drives, etc.