Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: flac behind the scenes with EAC... (Read 16932 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

flac behind the scenes with EAC...

Let's say you use flac as the external program for compression in EAC.  In your command line you use -V to verify the encoded files.  How can you tell if the verification failed or succeeded?

flac behind the scenes with EAC...

Reply #1
The FLAC documentation says about the -v option
Quote
Verify the encoding process. With this option, flac will create a parallel decoder that decodes the output of the encoder and compares the result against the original. It will abort immediately with an error if a mismatch occurs. -V increases the total encoding time but is guaranteed to catch any unforseen bug in the encoding process.

I have always used the -v option but as far as I know have never had it fail verification.  I always thought that it aborting if a mismatch occurred would mean that there would be no FLAC file created.  However, I am not certain about this.

flac behind the scenes with EAC...

Reply #2
I read that too.  So I've been checking the folder and making sure all the expected files are there.  I was just hoping there was an easier way to do it, like a log file or something.

flac behind the scenes with EAC...

Reply #3
Well, the question becomes, how does EAC process return codes from external programs? Anyone care to answer?

flac behind the scenes with EAC...

Reply #4
Quote
Well, the question becomes, how does EAC process return codes from external programs? Anyone care to answer?

Does it even see the return code?  My understanding was that all EAC did was open the encoder in a dos window.  Does EAC communicate with that window after it's creation?

flac behind the scenes with EAC...

Reply #5
Quote
I have always used the -v option but as far as I know have never had it fail verification.  I always thought that it aborting if a mismatch occurred would mean that there would be no FLAC file created.  However, I am not certain about this.

If verify fails, it will print a message saying so, along with a big ugly message about how to submit a bug, and a warning not to use the FLAC file.  The (possibly bad) FLAC file will be left there so it can be included in the bug report.  It also exits with a non-zero exit code.

But it's never failed for me either and I always encode with -V.  The only such bug reports I've ever gotten are from people who are overclocking or on flakey hardware.

Josh

flac behind the scenes with EAC...

Reply #6
As it does produce a FLAC file output this does then mean there might still be an issue if the encoding is being done as part of a rip in EAC.  I would imagine that the "big ugly message" would only be visible for a moment before the console window is closed.

Unfortunately I can't think of any way to test this.  Anybody got any ideas?

Could FLAC add some kind of tag to the generated file to indicate that verification failed?

flac behind the scenes with EAC...

Reply #7
Somebody put a script that returns nonzero as EAC's external codec and see what happens.

I'm too lazy.

flac behind the scenes with EAC...

Reply #8
Just wrote a little test app that simply copies the input file to the output filename, then prints an error message and exits with the return code 1.

The bad news is that there is no indication of the failure.  The console window closes immediately when the app terminates so the error message is not even visible briefly, and EAC seems to take no notice of the return code.

EAC does seem to be aware of the progress of the encoder after the DOS window is created because once the encoder app terminates it renames the file that the encoder creates from its temp name.

The process is as follows:
  • EAC rips the CD track to a wav file named after the song title, eg. Intro.wav
  • EAC renames the wav file to a temp name, eg. Itmp0(842.wav
  • The %s and %d parameters passed to the encoder are the temp names, eg Itmp0(842.wav and Itmp0(842.flac
  • When the encoder terminates and the DOS window closes, EAC renames the temp file, eg. Itmp0(842.flac to Intro.flac
This last step shows that EAC must be aware that the encoder process has completed, and yet it clearly does not take any notice of the return code as it will rename the temp file whether the return code is 0 or 1.

So, it looks like big error messages and return codes are no use with EAC.  One solution would be for FLAC to output a different named file if verify fails.  For example, instead of SongTitle.flac, it could generate SongTitle.VERIFYFAILED.flac.  Then we would still have the bad FLAC file for the bug report, but we would be able to see clearly that the verify has failed.  Josh, would you be happy to make this change in a future release of FLAC?

flac behind the scenes with EAC...

Reply #9
Quote
Just wrote a little test app that simply copies the input file to the output filename, then prints an error message and exits with the return code 1.

The bad news is that there is no indication of the failure.  The console window closes immediately when the app terminates so the error message is not even visible briefly, and EAC seems to take no notice of the return code.

...

So, it looks like big error messages and return codes are no use with EAC.  One solution would be for FLAC to output a different named file if verify fails.  For example, instead of SongTitle.flac, it could generate SongTitle.VERIFYFAILED.flac.  Then we would still have the bad FLAC file for the bug report, but we would be able to see clearly that the verify has failed.  Josh, would you be happy to make this change in a future release of FLAC?

much better would be to fix the bug in EAC.  try asking on the lists or forums (http://www.exactaudiocopy.de/).  ignoring the return code is bad for everyone.

Josh

flac behind the scenes with EAC...

Reply #10
Hmm... I just get a 404 "file not found" error if click on the Forum link at http://www.exactaudiocopy.de/

I will try again later and if I can get on I will make that suggestion.  However, I still think that even if EAC was modified, the change I suggested for FLAC would be a useful one.  It would make the verification failure even more clear and would guard against any other situations where the command line compiler is launched from an application that doesn't check the return codes.  I can't see any disadvantage in making this change.

flac behind the scenes with EAC...

Reply #11
Quote
Hmm... I just get a 404 "file not found" error if click on the Forum link at http://www.exactaudiocopy.de/

Bad news...

Quote
Unfortunately the forum had to be closed for the time being.  We have very large problem with our Hoster.

We get the forum software with the current Provider unfortunately not to run. 

A new Hoster have we already found with which we improvement to promise itself. 

We apologize for the long down-time.





Greetings



Digital-Inn Team

flac behind the scenes with EAC...

Reply #12
Now that the forum is back up at EAC, has anyone done anything about this?

flac behind the scenes with EAC...

Reply #13
I have created a thread on the EAC forum about this problem here.

flac behind the scenes with EAC...

Reply #14
phwip, I've backed you up in the thread - hope we see some action result from it

flac behind the scenes with EAC...

Reply #15
Andre thinks it might cause problems in EAC because he says that some encoders return a non-zero code for a successful encode.

I have suggested that perhaps there could be a box in the compression options where the user could enter the encoder's successful return code (eg. zero for FLAC).  If they do so and then the encoder returns a different value then EAC should report an error.

I am still awaiting a response from Andre on this, but if any of you has any better idea of a way round this problem then perhaps you could add your own post on the thead on the EAC forum (linked in my post above).  Note: you don't need to register on the EAC forum in order to post; simply put in a username and leave the password blank.

HOWEVER: I would still suggest that the change to FLAC to create a different file name (eg. SongTitle.VERIFYFAILED.flac) on verification failure would be a worthwhile addition.  Even if this issue does get resolved with EAC then it would still be a problem for any other frontend for FLAC that does not take into account the return code.

flac behind the scenes with EAC...

Reply #16
Hi Folks,

Damn! I spent weeks to design and set up my ripping with EAC into FLAC
to achive my collection to make sure that what I end up with is
guaranteed in quality, for which this site is excellent source. I've
already ripped 150+ albums, which almost killed me. And now I just
learned that --verify option did not safeguard me because EAC ignores
it.

In my opinion this is a clear cut EAC issue and by default EAC should
at least report non-zero exit code.  I agree that we could have a
option to allow abnormal encoders to return non-zero exit code and EAC
carry on as usual, but this must not be the normal setup. I guess we
have to wait for EAC developer to act.

In the meantime however I think we could create a wrapper around FLAC
or any external compressor for that matter which creates a logfile if
the external compressor returns with non-zero exit code. I will look
into this because I still have 50+ albums to go and I do not want to
change EAC or FLAC versions. I'll report back on this when I am done.

However my main issue is how to check the success of my existing 150+
rips without doing it again. So Josh or anybody who is familiar with
the innards of FLAC, could you help me with this? I have a few ideas

The manual says that it aborts IMMEDIATELY if there is a mismatch when
--verify option is used. Does this mean that that flac file would be
CORRUPT, that is, it would not be closed down properly (e.g. MD5
signature is not generated etc) if this --verify fails. Just because I
ran metaflac --add-replay-gain after EAC rip to calculate the album
and track replay gains (I encode each track into a separate
file). This is part of my post-processing script where I check exit
codes reigiously and I would expect that metaflac would have exited
with non-zero exit code if I had had a erroneous flac file due to
encoder failure when --verify is used. Is my expectation is correct?
If so I would not need to resort to other checks because as I said I
checked the exit code of metaflac religiously being a paranoid guy.

If not, then I also tell you that after 'metaflac --add-replay-gain' I
run 'flac -t' to ensure that metaflac did not corrupted the
files. (Now you see how paranoid I am.) So I assume that metaflac only
fiddles with replay gain metadata, but would maintain the corruptness
of the flac file. If so, I would expect that I can rely on 'flac -t'
to detect such a corrup flac file. Am I right?

If the immedate abort of flac when --verify fails may not corrupt the
flac file (because before it aborts it may close it down properly),
then I guess I am in a bigger trouble because, then I have to go back
an find an alternative check or rerip my albums. Josh or other FLAC
developer. Could you tell me if this case is possible?

If this latter case is possible, then I guess the only alterative
check I can come up with is to decode the files and check their play
time against the one recorded in the CUE sheet. I saved the CUE sheet
by EAC, which is not included into FLAC therefore it could not be
altered by FLAC even if --verify fails, and consequently it can be
trusted. If I had had a failure, then due to immediate abort of FLAC,
I assume, the decoded wav file would have been shorter than the length
recorded in CUE sheet unless I guess if the --verify had failed at the
very-very end. Am I right? If I have this extreme case, that is, it
failed at the very very end, how long playtime corruption could slip
through this test undetected?

Many thanks for your help and for the great FLAC compressor, which I
chose because of its rigorous testbed and --verify option because the
last thing I want is corrupted achives.

Triza

PS: My 1st post. I hope it shows up correctly.

flac behind the scenes with EAC...

Reply #17
1) Post is good, but you don't have to press enter to make lines yourself  just write normal paragraphs.

2) I didn't make that many rips myself, but I never had (or heard of) Flac failing on encode. So I think you are safe there. Also the word "encode" is misleading when applied to Flac. mp3, aac, ect. are encoders. Flac is a compressor (like RAR, but for music) so if it makes an error, it must be audible. Since it would be if you compress a .wav file with WinRar and WinRar makes a mistake. either it will skip, or will make a weired noise.
The Plan Within Plans

flac behind the scenes with EAC...

Reply #18
FLAC is opensource, just make some additions to the source... 

flac behind the scenes with EAC...

Reply #19
Quote
FLAC is opensource, just make some additions to the source...  :ph34r:

Yes, but as I said FLAC is fine. EAC which is faulty. EAC's source is closed.

As for my case, I decided that I am going to make a wrapper around FLAC call which will log if there is a flac failure. This way I do not have to upgrade FLAC or EAC, which I definitely do not want to do.

My major concern is the 150+ albums I already ripped.

flac behind the scenes with EAC...

Reply #20
Quote
1) Post is good, but you don't have to press enter to make lines yourself  just write normal paragraphs.


Yup I realised that. Thanks.

Quote
2) I didn't make that many rips myself, but I never had (or heard of) Flac failing on encode. So I think you are safe there.


That is why I am resonably confident now. Still I am paranoid.

What make matters worse is that I had flac failures during my post-processing (containing metaflac --add-replaygain and flac -t calls) initially which I traced down to a dodgy USB PCMCIA card (after 1 day HW testing). I am reasonably confident that this HW problem has been eradicated and I do not have overclocking and other nonsense. It never occurred again during 150 rips, but now I feel that there is a possibility that --verify failed due to some possibly remaining HW problem and if FLAC closes the file down gracefully in this case, then my post processing could not detect the failure.

Quote
Flac is a compressor (like RAR, but for music) so if it makes an error, it must be audible. Since it would be if you compress a .wav file with WinRar and WinRar makes a mistake. either it will skip, or will make a weired noise.


Well, just because it is a compressor it does not guarantee that the error is audible. But this is a moot question to me because I do not want to listen to my rips just now, but I would like to finish this project and stash away my originals and be reasonably confident that my rips are of excellent quality.

I could read the FLAC code, but it could take a long time to make the conclusion I am looking for. So if Josh, the FLAC developer does not come forward with some good news I have to implement my alternative check.

flac behind the scenes with EAC...

Reply #21
Quote
The manual says that it aborts IMMEDIATELY if there is a mismatch when --verify option is used. Does this mean that that flac file would be CORRUPT, that is, it would not be closed down properly (e.g. MD5 signature is not generated etc) if this --verify fails. Just because I ran metaflac --add-replay-gain after EAC rip to calculate the album and track replay gains (I encode each track into a separate file). This is part of my post-processing script where I check exit codes reigiously and I would expect that metaflac would have exited with non-zero exit code if I had had a erroneous flac file due to encoder failure when --verify is used. Is my expectation is correct?

I would expect that if verify failed, then flac -t would also fail, unless the verify decoder failed because of a mismatch of decoded audio data.  every time I had a report like that it turned out to be a hardware problem.

Quote
If not, then I also tell you that after 'metaflac --add-replay-gain' I run 'flac -t' to ensure that metaflac did not corrupted the files. (Now you see how paranoid I am.) So I assume that metaflac only fiddles with replay gain metadata, but would maintain the corruptness of the flac file. If so, I would expect that I can rely on 'flac -t' to detect such a corrup flac file. Am I right?

metaflac --add-replay-gain would fail if flac -t fails.  it only touches the metadata and doesn't try to repair errors.

Quote
If this latter case is possible, then I guess the only alterative check I can come up with is to decode the files and check their play time against the one recorded in the CUE sheet. I saved the CUE sheet by EAC, which is not included into FLAC therefore it could not be altered by FLAC even if --verify fails, and consequently it can be trusted. If I had had a failure, then due to immediate abort of FLAC, I assume, the decoded wav file would have been shorter than the length recorded in CUE sheet unless I guess if the --verify had failed at the very-very end. Am I right? If I have this extreme case, that is, it failed at the very very end, how long playtime corruption could slip through this test undetected?

this is probably reliable.  but if you're really worried, try tweaking mareo to rip to wav and flac, then add a step at the end to decode the flac to a temporary wav and compare.

Josh

flac behind the scenes with EAC...

Reply #22
Quote
HOWEVER: I would still suggest that the change to FLAC to create a different file name (eg. SongTitle.VERIFYFAILED.flac) on verification failure would be a worthwhile addition.  Even if this issue does get resolved with EAC then it would still be a problem for any other frontend for FLAC that does not take into account the return code.

Josh, are you dead set against this idea?  If so, why?

flac behind the scenes with EAC...

Reply #23
Quote
The manual says that it aborts IMMEDIATELY if there is a mismatch when
--verify option is used. Does this mean that that flac file would be
CORRUPT, that is, it would not be closed down properly (e.g. MD5
signature is not generated etc) if this --verify fails.

One failed on me before.  If I remember correctly there was just no flac file created.  That's why I always check the album to make sure all the tracks are there.

flac behind the scenes with EAC...

Reply #24
Quote
Quote
HOWEVER: I would still suggest that the change to FLAC to create a different file name (eg. SongTitle.VERIFYFAILED.flac) on verification failure would be a worthwhile addition.  Even if this issue does get resolved with EAC then it would still be a problem for any other frontend for FLAC that does not take into account the return code.

Josh, are you dead set against this idea?

no, it's actually growing on me.  will probably be in the next release, whenever that is.

Josh