Trader's Little Helper

[roann]

Originally Posted by jb1954

I wonder how hard it would be to make a linux version of your program ...

Don't know, never used linux. Besides my programming knowledge is really bad when it comes to C and/or C++.

Originally Posted by jb1954

... or are you eventually looking to sell it. ...

Never ... well, never say never, if I'd get a few million US dollars ...

Originally Posted by jb1954

... If it was opensource those hackers on linux would add to it making it even better. ...

TLH won't be open source.

Robert

[Dweller_Benthos]

Got a problem with a recent download (I can give a link if need be, it's on Dime) where while testing with TLH, get the error "file is possibly truncated or corrupt." When I try showing details I get:

length expanded size cdr WAVE problems filename
9 [main] shntool 932 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
10 [main] shntool 2624 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
10 [main] shntool 1600 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
21 [main] shntool 1196 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
10 [main] shntool 1924 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
14 [main] shntool 836 C:\WINDOWS\shntool.exe: *** fatal error - C:\WINDOWS\shntool.exe: *** fork: can't reserve memory for stack 0x239970 - 0x240000, Win32 error 487
15 [main] shntool 2812 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11
shntool: fork: Resource temporarily unavailable

error while forking child process, see above

There were errors.

The files play fine in Winamp, and MKWACT by itself seems to decode them just fine.

Any thoughts?

D_B

[roann]

Originally Posted by Dweller_Benthos

Got a problem with a recent download (I can give a link if need be, it's on Dime) where while testing with TLH, get the error "file is possibly truncated or corrupt." When I try showing details I get:

The files play fine in Winamp, and MKWACT by itself seems to decode them just fine.

Any thoughts?

D_B

If you're using version 0.x.x.x or 1.x.x.x please upgrade. If you're already using version 2.x.x.x post/pm/email the dime link so I can do some tests.

Robert

[Dweller_Benthos]

Yep, that fixed it though there's still a problem with one track, but I think that's truely corrupted. TLH won't decode it, says there's a problem

error while transferring data (likely file is truncated or otherwise corrupt, or disk is full)

The disk isn't full :-) so it's corrupted. MKWACT will decode the first 2 minutes or so, then just gives up.

Here's the torrent if you want to look:

http://www.dimeadozen.org/torrents-d....php?id=186329

The bad track is disk 1 track 8, listed as "Changes" but it's actually "Owner of a lonely heart".

D_B

[roann]

Originally Posted by Dweller_Benthos

Yep, that fixed it though there's still a problem with one track, but I think that's truely corrupted. TLH won't decode it, says there's a problem

The disk isn't full :-) so it's corrupted. MKWACT will decode the first 2 minutes or so, then just gives up.

Here's the torrent if you want to look:

http://www.dimeadozen.org/torrents-d....php?id=186329

The bad track is disk 1 track 8, listed as "Changes" but it's actually "Owner of a lonely heart".

D_B

Thanks for the info!

I downloaded disk 1 track 8 to run a couple of tests. shorten stops when the decoded data is about 24 MB - as usual without any error message. shntool stops after decoding 35% of the source file saying "error while transferring 68631360-byte data chunk -- skipping" (that data chunk size is way too big). So disk 1 track 8 is corrupt.

Robert

[Dweller_Benthos]

OK, thanks, I'll pass that info along.

D_B

[johnnydesoto]

Hello,

I hope this isn't too dumb a question but can someone explain this message received when testing encoded audio? :

"file is decodable without error, but flac fingerprint does not match"

I've also gotten this message when verifying files

"failed verification (checksum in file header does match, but checksum of audio data does not match"

I'm using the most recent Traders helper

thanks

[johnnydesoto]

those messages were for the same fileset btw

[jonohull]

Is this acceptable lineage?:

Silver CD> wav> flac> download> wav>cool edit repair>wav> flac

[glens]

Originally Posted by jonohull

Is this acceptable lineage?:

Silver CD> wav> flac> download> wav>cool edit repair>wav> flac

Is this how the lineage was indicated in a torrent you downloaded or one you want to upload?
Usually the extraction program used for the Silvers should be designated (e.g., EAC or CDParanoia for OSX). In addition, not necessarily a pure lineage thing, but if any audio editing was used, what was done insofar as any speed correction, EQ, noise reduction (shudder.....) Also, I know nothing, of course, but I've never seen "download" indicated in any lineage.....

[roann]

Originally Posted by johnnydesoto

Hello,

I hope this isn't too dumb a question but can someone explain this message received when testing encoded audio? :

"file is decodable without error, but flac fingerprint does not match"

I've also gotten this message when verifying files

"failed verification (checksum in file header does match, but checksum of audio data does not match"

I'm using the most recent Traders helper

thanks

At first sight the answer may be confusing because it's a lengthy technical one. So please read carefully.

(1) Error message "file is decodable without error, but flac fingerprint does not match"

When encoding a wav file to flac format the flac encoder calculates a checksum of the raw wave data (the so called flac fingerprint) and stores it in the header of the flac file. When decoding a flac file back to wav format the flac decoder not only decodes the data but additionally creates a checksum of the decoded data and compares it against the flac fingerprint.

So the error message tells you that a) there weren't any errors in the decoding process but b) the re-calculated checksum does not match the fingerprint. In other words, either the checksum header part or the audio data part of the flac file is corrupt.

Most times it's the audio data simply because it is by far the biggest part of the flac file (the checksum part is only a few bytes long). Usually this happens when you backup files on CD or DVD (either there was a bad write or the CD/DVD becomes corrupt over the years).

(2) Error message "failed verification (checksum in file header does match, but checksum of audio data does not match"

When testing a .ffp file three checksums are involved with each flac file listed in the checksum file. The first checksum (#1) is the one given in the checksum file, of course. The second one (#2) is the flac fingerprint (see above). The third one (#3) is the re-calculated checksum from the decoded audio data (see above).

TLH compares each checksum against the other ones. The error message tells you that a) the checksum in the .ffp file (#1) matches the flac fingerprint (#2) but b) the re-calculated checksum of the decoded data (#3) does not match these two ones. In other words, either the checksum header part or the audio data part of the flac file is corrupt.

For creating a .ffp checksum file all programs that are able to do that just read the fingerprint from the flac file header, but there isn't any checking done whether the file is still valid or not. So most likely the following has happened: The checksum header part or the audio part of the flac file for any reason became corrupt. A .ffp checksum file was created after the corruption took place. So checksums #1 and #2 do match but checksum #3 does not match.

Robert

[johnnydesoto]

thank you very much.

I was confused because it sounded like a corrupt file but it said that it would decode properly, which (if I understand correctly) means that it would decode corrupted since the .ffp was made after the corruption took place.

As an example: source audio in wav form>flac compression>wav(and a corrupted transfer)>recompressed to flac.

[roann]

Originally Posted by johnnydesoto

thank you very much.

I was confused because it sounded like a corrupt file but it said that it would decode properly, which (if I understand correctly) means that it would decode corrupted since the .ffp was made after the corruption took place.

As an example: source audio in wav form>flac compression>wav(and a corrupted transfer)>recompressed to flac.

Unfortunately I told you some crap in my last answer, really sorry for that. Don't know what happened when I posted this ... most likely I'm too old for all this newfangled technical stuff, or maybe for a short time my brain was taken over by some aliens who wanted to know everything about TLH, or I was just too diverted by my girl friend who from time to time tries to "convince" me that I can have more fun with her instead with my computers ;-) ...

Anyway, it's the "... either the checksum header part or the audio data part of the flac file is corrupt. Most times it's the audio data ..." statement that's wrong. If you experience one of the error messages we're talking about in most cases it is *not* the audio part because there wasn't any error during the decoding process (and it's very hard to fool the flac decoder). So most likely the raw audio data is *not* corrupt.

Robert

[johnnydesoto]

lol..ok thanks

[velvetsailor]

Awww, man... I don't mean to sound ungrateful, because it's got to be hard to even imagine all the time and "TLC" that have gone into TLH (and thank you very much!), but I think someone should wake me up if and when TLH looks a little less like rocket science, really.

Last time I tried TLH was back around the Windows Security bug announcement here, and all I could get it to deal with .WAVs, but back then I was thinking I wanted to do whatever it took to get the shntool fingerprints for .SHNs for TTD posts, so at the same time I installed shntool not realizing there were issues between TLH and the particular version, that were stated here but were not stated on the download page for TLH where I got it. I tried everything I could think of (or read about here) to get rid of shntool but still could not get TLH to deal correctly with anything but .WAVs, and just gave up. After that, I still have not caught up with changes to TLH.

So, as always, mkwACT is where I end up back at, because that, I can get to actually work in the here and now when I need it. In fact, other than its distaste for those ubiquitous lines that begin with ye olde octothorpe #, I have never had a single difficulty with it nor needed to force my tiny brain to try to contend with many pages of complicated support for it.

Being the case that mwkACT chokes on info inside the .md5 file that it considers to be spurious, like the lines that identify the file as having been created by TLH or the MD5 Summer, I've copied and renamed and edited hundreds and hundreds of md5 files for torrents that were created by TLH, everything with the "spurious text" gets an extra edited .md5 file that will plainly state "all files verified correctly" with mkwACT - that is on top of the extra md5s that get generated to monitor corruption in text files and artwork images, since a lot of the md5s I get with torrents address only the audio files and not other contents. And then I pass them onto people who probably don't get why there are sometimes 3 or 4 checksum files with a single show, or the protocols I use to try make sure that they too can get a straight answer out of mkwACT, just by clicking on a single md5 file.

And I realize that this is splitting hairs somewhat, because I think mkwACT should announce file corruption in addition to announcing that it found characters it doesn't like, but this stuff can be pretty disconcerting for the novice user - it took quite a long time for me to fully trust that mkwACT wasn't one of those programs that stops on the first few errors it finds and then fails to announce additional ones.

And this is technically mkwACT's problem rather than TLH's of course, but if I've understood correctly, I probably shouldn't expect a fix from MKW?

So on behalf of myself and anyone else who may still be in this same boat, I'm wondering if it would be possible / adequate if TLH put an identifier for md5s that it created, into the md5 file name or elsewhere, instead of into the md5 files themselves, so that these files will give a straight readout with mkwACT. Windows displays a date of creation for the md5 file anyway, so I'm guessing the date of creation doesn't actually need to be stated in the md5 file itself at least?

And I know, this would be applicable to MD5 Summer as well, but 95% of the files in question came from TLH.

Or is all this just lazy and completely ignorant of me? (Likely so, and apologies if it is).