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: EAC+Lame Logfile incorrect? (Read 3162 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC+Lame Logfile incorrect?

Good evening!
I just ripped a CD to .mp3 and asked for a logfile as well. On the log doesn't appear the .mp3 but just the .wav that was created between the .cda-track and the .mp3-file and I was wondering if that is usual (I mean to remember that I saw logfiles writing about .mp3 compression)?

Example:
Used drive  : SAMSUNG CDRW/DVD SM-348B  Adapter: 1  ID: 0
Read mode  : Secure with C2, accurate stream, NO disable cache
Read offset correction : 0
Overread into Lead-In and Lead-Out : No

Used output format : C:\Program Files\lame-3.90.3\lame.exe  (LAME MP3 Encoder)
                    192 kBit/s
                    Additional command line options : --alt-preset extreme
(...)
Track  1
    Filename D:\My Downloads\test\Xaver Fischer Trio - Songs For Your ()\01 - I Sing This Song Just For You.wav

    Peak level 99.2 %
    Track quality 100.0 %
(...)
No errors occured


Isn't that weird?

JD

btw I'm using EAC v0.95

EAC+Lame Logfile incorrect?

Reply #1 –
no bug really as your encoding was done by an external compressor

EAC+Lame Logfile incorrect?

Reply #2 –
Yeah, no bug. EAC always rips to wav first regardless, then encodes the files. But if you want you could always open the log in Notepad and do a Replace (CTRL+H). 

EAC+Lame Logfile incorrect?

Reply #3 –
mh thank you...

Really - I thought I've seen mp3 logs...but maybe those were internal compressors!

Good to know; but it would be very helpful to have a logfile for the "endproduct" cause my experience is that in the compression is the dog burried (as you say in german  ). I think many or even most of the problems appear during the compression process.

JD

EAC+Lame Logfile incorrect?

Reply #4 –
in addition:

There's no use in a logfile when you fake it! Right?

JD

EAC+Lame Logfile incorrect?

Reply #5 –
LAME is a pretty known and stable codec.  Its "--alt-preset standard"  parameters will yield files which can be indistguishable to most people in an ABX test as has been demonstrated in this forum.  What is the problem??   
Nov schmoz kapop.

EAC+Lame Logfile incorrect?

Reply #6 –
Well, I know LAME is pretty stable...but still would it positive to see it in a written form because: the codec might be stable but there is more around it that could influence right?
For example: I used to transcode mpc or ape to mp3 with Nero and LAME...same preset ...vbr exterme...but what happend was that I got corrupted files (hard to describe...sometimes they were longer than the track or you couldn't go forward and backward) and therefore it would be nice to have a proof for a correct compression.

JD

EAC+Lame Logfile incorrect?

Reply #7 –
Quote
Good to know; but it would be very helpful to have a logfile for the "endproduct" cause my experience is that in the compression is the dog burried (as you say in german   ). I think many or even most of the problems appear during the compression process.

Perhaps I have missed your point but it does post the info you seem to be after.

Quote
Used output format : C:\Program Files\lame-3.90.3\lame.exe (LAME MP3 Encoder)
192 kBit/s
Additional command line options : --alt-preset extreme


A) C:\Program Files\lame-3.90.3\
B) lame.exe
C) (LAME MP3 Encoder)
D) Additional command line options : --alt-preset extreme

There are circumstances where this is not always applicable; one example is if one were using M.A.R.E.O. in this case it is easy to deduct what EAC used for encoding.

Barring the use of a "Wrapper" application being used, with a bit of sleuthing around you can almost always figure out the encoder used by the cmd-line switches.

Here is a log of mine when ripping to FLAC:
Code: [Select]
Used output format : D:\Program Files\Exact Audio Copy\Encoders\flac-1.1.0-win\bin\flac.exe   (User Defined Encoder)
                     320 kBit/s
                     Additional command line options : -7 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" -T comment="Plextor PX-40TS; EAC 0.95, Offset corrected, Gap Detected, Test & Copy." %s
I have always used cmd-line encoders so it's hard to say whether the log says .mp3 when a dll is used, my opinion leans more toward it remaining as wav.

As far as faking logs, I doubt that this issue is high on Andre’s list of priorities, The intention is for your own records.

Take care, tec

(Nothing against M.A.R.E.O. I'm only using it as an example)

EAC+Lame Logfile incorrect?

Reply #8 –
Oh...I think we're talking at cross-purposes:
You are right that I have the proof that my file was compressed by LAME etc. BUT I do not know if the mp3 is compressed successfully or if there were any problems because thats only reported for the wav-rip:

Quote
Track 1 
Filename D:\My Downloads\test\Xaver Fischer Trio - Songs For Your ()\01 - I Sing This Song Just For You.wav

Peak level 99.2 %
Track quality 100.0 %
(...)
No errors occured


This Log is created by EAC so LAME has nothing to do with it and as a result cannot report any problems.

Or am I on a totally wrong track here???