[roann]

Sorry for being so late with a reply, but I wasn't at home for a couple of days.

Originally Posted by YokohamaJ

... ***EVERY*** time I try to fix sbes I always get this error message:

Preview of changes:
-------------------
C:\WINDOWS\shntool.exe (2796): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
3 [main] shntool 2704 sync_with_child: child 2796(0x6C4) died before initialization with status code 0x1
2545 [main] shntool 2704 sync_with_child: *** child state waiting for longjmp
shntoold: fork: Resource temorarily unavailable
Error: error while forking child process, see above ...

When fixing SBEs Trader's Little Helper acts as a frontend for the command-line application shntool, i.e. TLH tells shntool what to do, and then just catches the output of shntool. So that error message is an error message shntool creates, not TLH. If you would use shntool directly from the command-line (no TLH involved) you would get the same message. The problem is that Windows OS refuses to give shntool the memory needed. AFAIK this sometimes happens on WinXP SP2.

A way to get this "fixed"? Until now *nobody* could tell me what to do. Maybe someone on this list has the magic answer??? A few users reported that it helps to run TLH or the subcomponents shntool.exe, shorten.exe, cygwin1.dll in an older DOS compatibility mode WinXP offers. On other machines that doesn't help at all. Important: all the files "shntool.exe", "shorten.exe", "cygwin1.dll" have to be located in your *Windows* directory, and there have to be no other instances of these files (in Windows\system32, for example).

Originally Posted by YokohamaJ

... ***AND*** every time I try to verify ffps, I always get this error message on every track:

Line 001: file'gd86-12-31d1t01.flac'failed verification (checksum in metadata block does match, but md5 checksum does not match) ...

When you encode a wav file to flac format by default a checksum of the *wav* audio data (the so called flac fingerprint) is stored in the header of the flac file. *All* programs that create a ffp from an existing flac file just read that fingerprint from the flac file header. When verifying a ffp file TLH not only compares the ffp in the checksum file with the one in the flac file header, but additionally re-calculates the checksum from the *decoded* audio data and compares it against the other ones. This is the only way to *really* check if your flac file isn't corrupt.

The error message tells you that the checksum given in the checksum file matches the one in the flac file header, but if you decode flac audio back to wav audio and re-calculate the checksum of the wav audio, this checksum does not match. In other words, the audio data of the flac file has become corrupt, or the header of the flac file has become corrupt *before* someone made the ffp file.

It's strange that it occurs *every* time you try to verify flac fingerprints. Because shntool is involved in the verification process the reason could be the same as for the memory problem described in (1) ... but if so there should be the same error message ... You can run a test to see if the problem in (1) is the reason or if your flac files are really corrupt: take a wav file, then use flac frontend to encode it to flac format and to create a ffp file. Then use TLH to verify that ffp file. If there are no errors reported by TLH it's likely that your Dead files are corrupt ...

Originally Posted by YokohamaJ

... The other thing I've noticed is that when verifying md5s, especially on dvd-rs in my burner, it seems to take TLH much longer than mkwACT to get the job done. ...

Yeah, I know, it was stated earlier in this thread ... somewhere (still don't know where) during the process of creating/verifying a md5 checksum Trader's Little Helper slows down more and more (especially when working on DVDs). This will be fixed with the next release of TLH.

Robert