Did I rip properly? Options

[rgrybra]

Objective: CD --> high quality flac












...

This post has been edited by greynol: Jan 10 2010, 21:35

Reason for edit: Removed post icon.

[rgrybra]

...

CODE

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 10. January 2010, 7:38

Sir Charles Mackerras: Prague Chamber Orchestra / Mozart: The Symphonies [Disc 10]

Used drive : HL-DT-STDVDRAM GSA-T20N Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 667
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Not detected, thus appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : Yes
Command line compressor : C:\Program Files\foobar2000\flac.exe
Additional command line options : -6 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n"
-T "genre=%m" -T comment="%e" -T "comment=EAC (Secure Mode)" %s


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 7:02.00 | 0 | 31649
2 | 7:02.00 | 13:30.15 | 31650 | 92414
3 | 20:32.15 | 3:58.00 | 92415 | 110264
4 | 24:30.15 | 9:07.62 | 110265 | 151351
5 | 33:38.02 | 10:55.15 | 151352 | 200491
6 | 44:33.17 | 10:58.03 | 200492 | 249844
7 | 55:31.20 | 4:37.45 | 249845 | 270664
8 | 60:08.65 | 11:03.25 | 270665 | 320414


Track 1

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\01 - Symphony No. 40 in G minor, K 550 - I. Molto allegro.wav

Peak level 73.1 %
Track quality 100.0 %
Test CRC B235E169
Copy CRC B235E169
Accurately ripped (confidence 3) [6CDE1E8D]
Copy OK

Track 2

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\02 - Symphony No. 40 in G minor, K 550 - II. Andante.wav

Peak level 57.4 %
Track quality 99.9 %
Test CRC 2216EE35
Copy CRC 2216EE35
Accurately ripped (confidence 3) [78911E18]
Copy OK

Track 3

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\03 - Symphony No. 40 in G minor, K 550 - III. Menuetto · Trio.wav

Peak level 65.9 %
Track quality 100.0 %
Test CRC 86A2FC57
Copy CRC 86A2FC57
Accurately ripped (confidence 3) [E1894DE6]
Copy OK

Track 4

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\04 - Symphony No. 40 in G minor, K 550 - IV. Allegro assai.wav

Peak level 68.2 %
Track quality 100.0 %
Test CRC 3DFD5F05
Copy CRC 3DFD5F05
Accurately ripped (confidence 3) [4FFFEABE]
Copy OK

Track 5

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\05 - Symphony No. 41 in C major, K 551 'Jupiter' - I. Allegro vivace.wav

Peak level 85.7 %
Track quality 100.0 %
Test CRC 858CC141
Copy CRC 858CC141
Accurately ripped (confidence 3) [43419AB1]
Copy OK

Track 6

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\06 - Symphony No. 41 in C major, K 551 'Jupiter' - II. Andante cantabile.wav

Peak level 49.6 %
Track quality 100.0 %
Test CRC C2942F05
Copy CRC C2942F05
Accurately ripped (confidence 3) [33D46F92]
Copy OK

Track 7

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\07 - Symphony No. 41 in C major, K 551 'Jupiter' - III. Menuetto; Trio.wav

Peak level 48.5 %
Track quality 99.9 %
Test CRC 18143B39
Copy CRC 18143B39
Accurately ripped (confidence 3) [2F364ECB]
Copy OK

Track 8

Filename C:\Users\Rogelio\Desktop\Sir Charles Mackerras_ Prague Chamber Orchestra - Mozart_ The Symphonies\Mozart_ The Symphonies [Disc 10]\08 - Symphony No. 41 in C major, K 551 'Jupiter' - IV. Molto allegro.wav

Peak level 76.2 %
Track quality 100.0 %
Test CRC 814DC74E
Copy CRC 814DC74E
Accurately ripped (confidence 3) [07DA9D1E]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

This post has been edited by greynol: Jan 10 2010, 20:49

Reason for edit: Placed EAC log in a codebox.

[Bodhi]

CRC unchecked
add tag unchecked
Return code checked

This post has been edited by Bodhi: Jan 10 2010, 17:48

[_m²_]

If AccurateRip says it's confident it's fine, than nothing else matters. The rip is fine.

[NuSkooler]

You should always detect gaps first (F4) before ripping & set the option to append to previous track.

Also, I'd disable the ID3 tags option. In reality, it's not going to do anything to your FLAC rip at all, however.

[greynol]

Sorry, but this whole bit about people should always detect gaps first is complete and utter nonsense.

ID3 tags with flac files is a no-no!

rgrybra, instead of all the effort in providing screen shots, you could have just checked our wiki.

This post has been edited by greynol: Jan 10 2010, 20:48

[NuSkooler]

Sorry, but this whole bit about people should always detect gaps first is complete and utter nonsense.

I'd like to hear your explanation on such a claim.

rgrybra, instead of all the effort in providing screen shots, you could have just checked our wiki.

Or at least only post the log for review ;-)

[greynol]

I'd like to hear your explanation on such a claim.

It is you who has made a claim, not I. Now if you provide your reasoning why someone should have to detect gaps before ripping if they want them appended to the previous track, I'll gladly tell you why you're not correct.

[hidn]

compression monotone image, it is better to use the format PNG

[a3aan]

I'd like to hear your explanation on such a claim.

It is you who has made a claim, not I. Now if you provide your reasoning why someone should have to detect gaps before ripping if they want them appended to the previous track, I'll gladly tell you why you're not correct.

http://blowfish.be/eac/Rip/rip3.html?

[greynol]

Is that link supposed to justify the recommendation; and if so then how exactly?

This post has been edited by greynol: Jan 10 2010, 23:18

[NuSkooler]

I'd like to hear your explanation on such a claim.

It is you who has made a claim, not I. Now if you provide your reasoning why someone should have to detect gaps before ripping if they want them appended to the previous track, I'll gladly tell you why you're not correct.

If you're wanting the best possible exact copy of a disc, you're going to want a cue sheet; If you are to create a proper cue sheet, you need gap detection. This is so the 00 indexes can be properly aligned.

Being that gap detection is considered a requirement for 99.9% of the FLAC/archival community, I'd say it is you making a claim as to that it's "utter nonsense".

[greynol]

If you're wanting the best possible exact copy of a disc, you're going to want a cue sheet; If you are to create a proper cue sheet, you need gap detection. This is so the 00 indexes can be properly aligned.

Sorry, but this is wrong. If gaps aren't detected prior to creating a cue sheet, EAC will detect them automatically.

Being that gap detection is considered a requirement for 99.9% of the FLAC/archival community, I'd say it is you making a claim as to that it's "utter nonsense".

Your logical fallacy of appealing to authority is duly noted.

Would you like to try again?

This post has been edited by greynol: Jan 11 2010, 22:03

Reason for edit: Spelling.

[NuSkooler]

My original response to the OP was to point out that gap detection is important (and append to previous track specifically). I was unaware EAC would do detection when creating a cue sheet if you had not already. The point still stands.

It is nice to see that at least one of the moderators of this wonderful forum is a troll, however.

[greynol]

At least one of the moderators takes issue when people make recommendations about things they clearly don't understand.

You do realize that gaps are appended to the previous track without any need for gap detection (manual or automatic), right?

[twostar]

http://blowfish.be/eac/Rip/rip3.html?

If you think that guide has correct information, think again. This screenshot alone is proof the guy doesn't know what he's talking about.

This post has been edited by twostar: Jan 11 2010, 02:27

[greynol]

I used to think that guide was ok for the most part, but after looking over that specific section I'm under the impression that the person who wrote it is clearly not armed with all the facts. The example of the drive that caches 41kB as proof that EAC's caching test results were incorrect was completely misguided. A drive that caches 41kB does not need flushing since EAC requests 64kB worth of data. The part implying that cache flushing is required in order to detect read errors is false as well, but I don't see that as such a big deal other than it also shows that the author has not studied EAC as thoroughly as he could have.

This post has been edited by greynol: Jan 11 2010, 04:35

[Ryan Woloshen]

I used to think that guide was ok for the most part, but after looking over that specific section I'm under the impression that the person who wrote it is clearly not armed with all the facts. The example of the drive that caches 41kB as proof that EAC's caching test results were incorrect was completely misguided. A drive that caches 41kB does not need flushing since EAC requests 64kB worth of data. The part implying that cache flushing is required in order to detect read errors is false as well, but I don't see that as such a big deal other than it also shows that the author has not studied EAC as thoroughly as he could have.

Excuse me, Greynol. I am not what-so-ever contending with what you have to say, and am just looking to understand what you're talking about further. Can you explain why the fact that the drive caches 41kb of data, while EAC requests 64kb of data, means that you don't need to check that the drive caches audio?

[greynol]

Every single read request will flush the cache of whatever data was in it previously. There's a link to this cited in our wiki. In case you didn't look over the page in question, EAC (correctly for its own purposes) detected this particular drive as non-caching.