MP3 bestand ~0.025sec te lang na export met Lame MP3 encoder

[Saturnus]

De titel omschrijft het probleem al zo'n beetje volledig. Na het exporteren blijkt dat er ~0.025 seconde extra 'geluid' is gezet aan het begin van een MP3 bestand.
Ik heb gebruik gemaakt van Audacity (stable en beta) en Free MP3 WMA OGG Converter...
De eerste ook nog met verschillende versies (3.96, 3.98, 3.98.2 en 3.99) van Lame MP3 encoder (lame_enc.dll).

Ik snap dit niet. Dit is juist niet wat ik wil want hierdoor kan ik die bestanden totaal niet gebruiken als loopjes.

Dus...wat is de reden van die extra 'space' en is het mogelijk dat ik dit kan omzeilen?

[alt-92]

De enige versie die ik niet zie in je rijtje is 3.97 die heb ik hier slingeren in een oudere CDex (1.70b2)
Is dat met een reden?

oh, en >>>> CSA

[Saturnus]

3.97 stond niet op http://www.free-codecs.com/Lame_Encoder_download.htm.
Zou die wel 'goed' zijn? Ik denk dat het gewoon een kenmerk van MP3 is waar ik (laat) achter kom...of niet soms?

[mace]

En als je een WAV met de commandline encoder encodeert krijg je ook hetzelfde?

[Saturnus]

WAV naar MP3? Met GUI wordt dat langer ja. CLI ken ik niet.

[mace]

Saturnus schreef op zondag 07 juni 2009 @ 22:48:
WAV naar MP3? Met GUI wordt dat langer ja. CLI ken ik niet.

Nouja de Lame encoder is ook gewoon als .exe te krijgen, en dan kan je gewoon proberen om een wavje te maken en die dan met de CLI naar mp3 te encoderen, om te kijken of het verschil maakt.


Encodeer je VBR of CBR? Als het het ene is, probeer eens het andere.

[Saturnus]

mace schreef op zondag 07 juni 2009 @ 22:50:
[...]

Nouja de Lame encoder is ook gewoon als .exe te krijgen, en dan kan je gewoon proberen om een wavje te maken en die dan met de CLI naar mp3 te encoderen, om te kijken of het verschil maakt.


Encodeer je VBR of CBR? Als het het ene is, probeer eens het andere.

CLI/xBR verandert er niets aan.

[F_J_K]

IIRC:

MP3 gebruikt frames. De muziek zal niet precies N frames lang zijn, dus komt er een beetje stilte bij om het frame vol te krijgen. Niets aan te doen, anders dan geen mp3 gebruiken als het tot op de milliseconde moet worden getimed.

Edit: Google suggereert dat je misschien iets kunt met de Padding bit, maar ik heb geen idee hoe en wat.

[ Voor 18% gewijzigd door F_J_K op 07-06-2009 23:11 ]

[wheez50]

Audiostiltes in mp3's zijn bijna onoverkomelijk. Lame is vrij goed in de gap zo minimaal mogelijk maken, maar echt elimineren kan niet.

Meer info:
http://www.hydrogenaudio....index.php?showtopic=56478

Beste manier om gapless af te spelen is door de tracks in een keer te rippen. Dus als een grote mp3. Zie bijvoorbeeld:
http://www.geocities.com/...sicclassical/mp3gaps.html

Geen idee trouwens wat andere compressieformaten doen om de stiltes zo minimaal (/afwezig?) te houden. Ik gebruik trouwens audiograbber, en dan edit ik continuous tracks gewoon tot een hele grote. Dat naast dat ik de tracks ook afzonderlijk rip.

Van mp3's met gap is alleen herencoderen (reencoding ) eigenlijk een goede methode. Voor die mp3's die ik al heb, heb ik er gewoon mee leren leven.

(Disclaimer: Engelse ziekte is killing me.)

[RedPixel]

wheez50 schreef op zondag 07 juni 2009 @ 23:24:
Geen idee trouwens wat andere compressieformaten doen om de stiltes zo minimaal (/afwezig?) te houden.

Niet werken met frames, frames extreem klein maken, in de header aangeven welk deel van de laatste frame genegeerd moet worden (of de exacte lengte)?

[Henk007]

Als je een decoder gebruikt die gapless-aware is, is er niets aan de hand.
Bijvoorbeeld lame zelf of Foobar2000.

[ Voor 20% gewijzigd door Henk007 op 08-06-2009 08:54 ]

[ravenger]

ogg zou er geen moeite mee moeten hebben. In games is ogg de standaard, omdat we daarmee seamless kunnen loopen in tegenstelling tot mp3.

[Henk007]

De vraag van TS ging over mp3, maar inderdaad is vorbis gapless-by-design.
De audio codec heet vorbis en de container ogg; ik heb het niet verzonnen..