eac+lame+doet het niet :P

[mad_dog]

edit:

damn, typo in titel, moet natuurlijk eac zijn :\

hey, ik heb search al doorgezocht, maar dit probleem nog niet kunnen vinden
ik gebruik winXP sp1 up to date
eac nieuwste (die beta 4)
en lame 3.92

nouw ik wil de allerbeste kwaliteit hebben, dus dacht ik ik kies voor
--alt-preset insane %s %d
dit werkt perfect, alleen is dit JOINT stereo en LOWPASS filter
ik wil gewoon 320 stereo klaar, geen joint, geen filter (want dit is neem ik aan niet gelijk aan het origineel)

ik heb de volgende settings geprobeerd:
-b 320 -m s
deze deed het niet, dus probeerde ik de onderstaande(zou moeten helpen had ik ergens gelezen)
-b 320 -m s -h

owja, ik zeg nu wel werkt niet, maar hij maakt er een wav van, maar geen mp3, hij start dus lame niet op, komt denk ik omdat hij deze settings niet accepteert ofzow, iemand een idee?

maar weer geen effect..iemand een idee

[ Voor 5% gewijzigd door mad_dog op 08-01-2003 18:53 ]

[MisterDon]

Maak gewoon eerst wavs met EAC en zet die om met Lame icm RazorLame. Werkt supermakkelijk en je hebt meer controle over wat je aan het doen bent.

[mno]

Je kiest in EAC toch wel voor Copy selected tracks (compressed)? Kijk anders even in deze tutorial voor de instellingen: http://www.ping.be/satcp/cd2mp3.htm

[mad_dog]

jaja ik heb die tutorial gedaan, uiteraard, en veel meer gelezen, maar in die tutorial staat niet de optie uitegeld voor 320kb en stereo zonder filter shit...

verder wil ik t graag zonder razorlame doen, omdat het om mijn gehele cd collectie gaat en dat xtra werk is

[ShittyOldMan]

klinkt mij als een software probleem
av -> sa (+titelfix)

[satcp]

Tien tegen één een foute command-line opgegeven. Of je kiest "LAME MP3 Encoder" én gebruikt de %s en %d niet in de command-line, of je gebruikt "User Defined Encoder" met %s en %d. Deze % variabelen duiden aan waar op de command-line de bron- en doelbestandsnamen moeten komen. Als je "LAME MP3 Encoder" kiest, dan weet EAC dat reeds.

Raak je er dan nog niet uit, copy/paste dan eventjes de inhoud van een EAC log file hier. Daaruit valt meestal het probleem wel af te leiden.

Overigens zal "--alt-preset insane %s %d" een betere geluidskwaliteit geven dan "-b 320 -m s -h %s %d". De alt-preset instellingen zijn door onder andere Dibrom van Hydrogen Audio fijngesteld. Deze instelling maakt een veel efficiënter gebruik van de beschikbare bandbreedte dan de oude 320 kbps CBR instelling die jij poogt te gebruiken. De vraag is natuurlijk of je het gaat horen. 99% van de stervelingen hoort het verschil nooit.

Als je het verschil wel eenduidig hoort in een blinde luistertest is MP3 geen formaat voor u. Stap dan over op lossless coderingen zoals Monkey's Audio.

[mad_dog]

naja wat je wilt, ik dacht meer audio, aangezien de audiofreaks de juiste settings maybe eerder kennen, maar maakt niet uit, iig thx voor de titelfix, voel ik me minder stom

edit:

f*ck, dubble post, sorry, ging ff doorelkaar heen.....

[ Voor 19% gewijzigd door mad_dog op 08-01-2003 20:54 ]

[mad_dog]

Overigens zal "--alt-preset insane %s %d" een betere geluidskwaliteit geven dan "-b 320 -m s -h %s %d". De alt-preset instellingen zijn door onder andere Dibrom van Hydrogen Audio fijngesteld. Deze instelling maakt een veel efficiënter gebruik van de beschikbare bandbreedte dan de oude 320 kbps CBR instelling die jij poogt te gebruiken. De vraag is natuurlijk of je het gaat horen. 99% van de stervelingen hoort het verschil nooit.

is dat serieus waar, dat die insane beter is dan gewoon puur? hoe kan dat dan want dat is joint stereo ipv stereo.......?

[satcp]

Waar heb je het idee opgedaan dat joint stereo slechter zou zijn dan gewone stereo? Het is zo dat in het verleden vele codecs (Xing, Fraunhofer,...) een vreselijk slechte joint stereo implementatie hadden, maar dat ligt niet aan het principe van joint stereo. Joint stereo is gewoon een schakelmechanisme tussen gewone stereo en mid/side stereo. Joint stereo is geen aparte stereomode. Theoretisch kan een joint stereonummer dus volledig stereo zijn, of volledig mid/side stereo.

Stereo betekent natuurlijk dat beide kanalen apart worden gecodeerd. De klassieke methode, maar ook een met veel overhead. Veel componenten van het muzieksignaal zijn in beide kanalen aanwezig. Daarom is er mid/side stereo bedacht. Hierbij codeert men de verschilsignalen L+R (mid) en L-R (side). Deze methode vergroot de bandbreedte zeer effectief voor signalen met kleine kanaalscheiding. Het joint stereo schakelmechanisme is het algoritme dat bepaalt wanneer welke stereomode wordt gebruikt. Bij de "--alt-preset insane" instelling zal dat overwegend gewone stereo zijn omdat de beschikbare bandbreedte (320 kbit/s) voor de meeste frames voldoende is.

[mad_dog]

ahhh geniaal, bedankt voor je heldere uiteenzetting
dit had ik net nodig, ik dacht dat nl dat joint stereo zo was dat links en rechts niet goed gescheiden werden, dus dat je op stereo bijvoorbeeld uit R de hi-hat alleen hoort, en dat bij Joint stereo dan opeens in beide kanalen de hi-hat zit
want dat heb ik liever niet
maar ik begrijp dat met die setting insane het allemaal goed komt
dan dank ik jullie hartelijk en ga ik lekker mijn cds rippen in hoogwaardige kwaliteit

[mad_dog]

damn nieuw probleem...elk nummer mist de eerst 0,25sec, dus begint ie zeg maar niet zo mooi...
tis een dvd speler asus16-48
zou het daar aan liggen?
ik dacht, hijs nieuwer dan mijn brander moet dus wel beter zijn (is een lite on16-10-40)
is zon optie met spin up drive before extraction, maar dat schijnt ook weer nadelig te zijn voor kwaliteit, iemand een andere tip?


hmmm lijkt er op dat die dvd speler niet capable is of caching..
kan ik het dan toch beter in die lite on doen? (die heeft het wel)

[ Voor 16% gewijzigd door mad_dog op 09-01-2003 12:47 ]

[Justice]

Je kan op de webstie van EAC de offset zien van bepaalde cdspelers. En je kan thuis met cds waarvan een bepaalde code op de website staat, zelf de offset berekenen. even checken dus

[Sander Schrier]

Ik heb dezelfde DVD-speler, misschien helpt het door naar 'Drive Options' te gaan en op het tabblad 'Offset / Speed' een offset van +594 in te geven. Die waarde heeft EAC zelf uitgezocht aan de hand van een aantal CD's die in een daarvoor aangelegde database zijn opgenomen....

Edit: dit sluit dus aan op het verhaal van Justice hierboven

[ Voor 16% gewijzigd door Sander Schrier op 09-01-2003 12:56 . Reden: Toevoeging ]

[mad_dog]

hmm weird, als ik zelf zoek op detect ofset vind hij elke keer +/-2766

moek dan die +594 van Trent nemen of de waarde die hij vindt

en is dat trouwens de enige optie die anders moet (alleen het veldje "use read offset correction)
* mad_dog heeft van offsets totaal geen verstand

idd dit staat WEL in de algemeen bekende tutorial

[ Voor 12% gewijzigd door mad_dog op 09-01-2003 13:58 ]

[satcp]

"Spin up drive before extracting" is bedoeld voor oude drives die geen correcte data lezen als ze nog niet op volle leessnelheid zijn. Daarom kun je deze optie inschakelen om de drive eerst op leessnelheid te brengen en dan pas te starteb. De instelling heeft geen nadelige gevolgen bij moderne cd-romspelers, maar is gewoonweg zinloos. Er is me geen enkele ietwat recente drive bekend die nog lijdt onder dit euvel.

Wanneer een drive geen audio cachet is dat net beter dan een drive die wel audiodata buffert. Dan kan EAC veel sneller werken. Praktisch gezien leest EAC elke sector tweemaal en vergelijkt deze. Gezien de kans vrijwel negeerbaar klein is dat tweemaal identiek dezelfde foute data wordt ingelezen is dit een erg betrouwbare foutdetectiemethode. Stel nu dat de drive audiodata buffert. EAC vraagt tweemaal een sector uit te lezen aan de cd-rom en vergelijkt deze. Omdat de drive buffert zal de eerste sector fysisch van de cd worden gelezen, maar de tweede (zelfde sector weliswaar) wordt uit het buffergeheugen van de drive gehaald. Dit is natuurlijk vanuit de fabrikant's oogpunt gedaan om snelheidswinst te halen. Uit het buffergeheugen lezen is veel sneller dan weer op de cd te gaan lezen. Bij data gaat dit verhaal op, maar audio is veel gevoeliger voor fouten. Daarom dat je ook software als EAC gebruikt. Als de eerste sector fout gelezen werd van de cd en EAC vraagt deze nogmaals, dan wordt diezelfde foute sector uit de buffer aan EAC gegeven. EAC vergelijkt en ziet dat ze identiek zijn. EAC zal in dit geval dus foutief aannemen dat de sector correct was.

Gelukkig bezit EAC routines om dat te vermijden. Hierbij wordt als het ware de buffer leeggemaakt tussen elke leespoging. Het moge duidelijk zijn dat dit proces tijd kost. Daarom is een cd-romspeler zonder audio buffering steeds sneller in EAC als een met. Maar het is van groot belang dat je de disable cache functie in EAC inschakeld als je een drive hebt die buffert. Anders worden geen fouten gedetecteerd!

Een offset van +2766 is erg hoog en dus ook erg onwaarschijnlijk. Je mag nooit een offset test doen met EAC met slechts 1 cd. Je moet voor minstens 2 verschillende cd's dezelfde offset bekomen. Anders is de offset waarde nooit betrouwbaar.

Gezien de oudere 12x Asus DVD ook een offset heeft van +594 lijkt dit me de correcte Read Offset Correction.

Wil je meer weten over offsets, lees dan m'n pagina The Truth About Offsets. Hierin beschrijf ik gedetailleerd wat offsets zijn en hoe je ze vermijdt indien mogelijk. In Determining The Offsets Part I en Determining The Offsets Part II wordt beschreven hoe je zelf de offsets van je drive kan bepalen.

Nu moet ik wel zeggen dat offsets zich uiten in milliseconden. Niet een kwartseconde. Je ript toch geen live of gemixt album waarbij de nummers in elkaar overlopen (of in mekaar in/uit faden). In dat geval kan het natuurlijk zijn dat een stuk van de muziek nog in de vorige track stond. In zeer zeldzame gevallen is de cd zelf fout en staan de indices verkeerd. Probeer even met een andere cd of je het probleem daar ook nog hebt.

[mad_dog]

wederom bedankt voor je verhelderende stukje


(ik zit idd die 3paginas te bestuderen nu, zeer duidelijk neergezet )
dr blijft 1ding heel raar, ik net al mijn cds is te voorschijngehaald en ben gaan testen (originele uiteraard)
het gekke is de ene cd is -1700 de volgende +1349
dit klopt denk ik niet, ik heb met verschillende cds geprobeerd, van metallica to spice girls tot michael jackson en de prodigy

iemand idee wat dit kan zijn?

opvallend detail met dezelfde cd bepaal ik elke keer opnieuw dezelfde offset(bijv elke keer +1234), maar stop ik andere cd dr in krijg ik weer een andere(elke keer +345)

[ Voor 27% gewijzigd door mad_dog op 09-01-2003 14:26 ]

[satcp]

Dat is net wat ik wil zeggen en wat je ook kan lezen in m'n handleidingen. EAC bevat een lijst van referentie-cd's. Jij kan diezelfde cd hebben, maar daarvoor hoeft dat niet dezelfde persing te zijn. En schijnbaar ontstaan er offsets tussen verschillende persingen. Ik weet ook niet juist waarom dat zo is, maar men schijnt niet steeds dezelfde master te gebruiken. Anyway, het gevolg is dat de meeste cd's die je hebt uit EAC's referentielijst dus verschillend zijn en bij gevolg ook een verschillende offset zullen geven. Pas als je 2 of meer cd's hebt die dezelfde offset geven weet je dat je dit dezelfde cd's zijn als in EAC's database. De waarde die je dan bekomt is je offset.

In theorie bestaat er natuurlijk nog de kans dat twee willekeurige cd's dezelfde offset geven terwijl ze niet identiek zijn aan die van EAC's database, maar ik denk dat je die kans wel negeerbaar klein kan maken. Ik heb alleszins nog nooit van zulk een geval gehoord

Mocht je in het bezit zijn van een Plextor PX-32TS cd-romspeler dan kun je Andre helpen met het uitbreiden van de EAC referentiedatabase.

[mad_dog]

nee sorry die speler heb ik niet
en het blijkt dat ik weer is te snel was, sorry
schaam me dood, maja iig erg bedankt ga ik is ff verder met zoeken


sow gelukt hoor, alle cds uit het hele huis verzameld en zitten zoeken naar juiste codes :y)
uiteraard gevonden en idd t was +594 geniaal gewoon :devil:
bedankt voor ieders hulp en ik hoop dat de mp3tjes nu eindelijk goed dr uitkomen

[ Voor 44% gewijzigd door mad_dog op 09-01-2003 15:15 ]

[mad_dog]

owowow, nouw voel ik me echt n00b...
ik heb de offset ingesteld, maar nog steeds mis ik iets van het begin van het nummer..
het moet wel aan de mp3 liggen, aangezien de cd het wel goed doet in dezelfde player...

[Sander Schrier]

Heb je nog WAV's staan die je hebt geripped? Dan kun je luisteren of het encoden naar MP3 ligt, of dat het al eerder bij het rippen al fout gaat...

De offset van +594 is inderdaad aan de hand van een vijftal CD's op de referentielijst verkregen. Als je ook de ASUS DVD-ROM E616 hebt, moet het kloppen...

[ Voor 37% gewijzigd door Sander Schrier op 09-01-2003 15:49 ]

[mad_dog]

wh000t de wav had het ookt.........
ik heb toen 10 keer achterelkaar dit gedaan: stop-->play
de ene keer starte hij goed de andere keer niet
ik winamp gestart en idd...deze deed zowel de wav als de mp3 goed
kortom wmplayer doet het begin van de mp3tjes/wav niet goed maar de cds wel
naja t zal wel, mijn mp3tje is iig goed

[satcp]

Windows Media Player... Daar heb je je probleem al. Gebruik liever een echte player als WinAMP. Met Windows Media Player heb ik zelf ook al zulke verschijnselen gezien.

[mad_dog]

owkee, het gaat lekker nu, mooie mp3tjes zonder knarsje, met mooi begin, great work, thx alot allemaal

ik vroeg me alleen af waarom de ene cd op 12speed ript en de andere op 3.....zelfde settings.....
echt weird, maakt dat nog uit voor de kwaliteit..?
lijkt me niet he....

[satcp]

Leessnelheid maakt niet uit, maar trager betekent waarschijnlijk dat EAC er meer moeite mee heeft. Meer krasjes op de cd ofzo. Zolang EAC geen fouten aanduidt in de log is er echter niets mis met de kwaliteit.

[mad_dog]

owkee, geniaal, t zijn allemaal bijna krasloze cds, maar de logs kloppen
wat is btw een sync error, heb ik soms wel, dan doet hij heeeeel lang over 1 nummer......

[satcp]

Sync errors duidden op een synchronisatiefout. Bijvoorbeeld wanneer EAC even het spoor bijster is door zware krassen. Deze kunnen hoorbare artifacten geven. Maar sync-fouten kunnen ook ontstaan door verkeerde drive-instellingen. Als de sync-fout zich enkel voordoet op positie 0:00:00 in een track of helemaal op het einde van de track, dan is het waarschijnlijk een verkeerde instelling. Er is niet een eenduidig antwoord in deze situatie, maar vaak is de optie 'Overreading into Lead-In/Out' de boosdoener. Als deze ingeschakeld is moet je deze eens uitschakelen en zien of ie nog zulke sync-fouten geeft.