Een DivX file van precies 1400 MB splitten 2x700

[Majestic]

Met Fair Use een DivX file gemaakt.
Geluid eronder Mp3 160 k/bit p/s.

Nu is de Film precies 1400 MB op de byte nauwkeurig (leve Fair Use). Maar nu kan ik met Virtual Dub wel gaan knippen om de file te splitten maar de film is met een Variabele bitrate gecodeerd. Precies het midden kwa tijd is dus niet precies het midden kwa bestandsgroote. Zijn er progjes die dit tot op de bit nauwkeurig kunnen ?

Avichop is ruk, Virtual Dub niet nauwkeurig genoeg.

Wie weet raad.

[Verwijderd]

denk dat je het geluid moet mp3'en naar 128 wil je de film niet abrupt afknippen.

[TD-er]

Ik neem aan dat je bedoeld dat de audio met vbr is geencoded.
Dan heb je nu ook al (in het origineel) dat het geluid niet perfect synchroon loopt met het beeld.
Dit omdat een AVI-file een vast aantal bytes aan audio verwacht per frame (of althans per tijdseenheid, elk frame hoeft niet precies even lang te duren)
Ik denk dus dat Virtualdub wel nauwkeurig genoeg is (die pakt precies dat gedeelte aan audio wat bij een frame hoort precies zoals de mediaplayer bijvoorbeeld doet)
Ik ou het dus eerst ff met virtualdub proberen (kost maar een paar minuten, wanneer je 2 HDD's hebt)

[Majestic]

Audio is niet VBR maar een constante 160 kbit/s.

Het probleem met Vdub is dat het niet aangeeft hoe groot de file in het midden is. Wat zeg maar voor de streep zit en wat na, alleen hoeveel tijd en hoeveel frames.

[scorpionv]

Ik heb een andere oplossing voor je, je her-comprimeert de audio met LAME - VBR op 192 kbits maximaal. In de praktijk kom je dan rond de 135 kbit gemiddeld uit. Dan heb je wat speling om de film niet precies in het midden te moeten splitsen, je kan dan iig ook fatsoenlijk op een scenewisseling splitsen. Zo probeer ik meestal een beetje rond de 1280 of 1380 uit te komen, een beetje speling is gewoon lekker.

[fredkroket]

AVICHOP, werkt perfect

[TD-er]

-edit: (= oorspronkelijke reactie)
Je kunt toch gewoon kijken hoeveel frames de film totaal is (# frames/sec is constant)
dan pak je de zakjapanner en deel je dat aantal door 2 (eventueel afronden naar dichtst bijzijnde keyframe)
dan moet het goed gaan
----------------------
Bovenstaande was mijn oorspronkelijke reactie, maar nu zie ik inderdaad het probleem ook (zat te of )

Je moet wel goed opletten of je op een keyframe zit te snijden, want anders krijg je rare fouten aan het begin van de 2e helft.
Ik denk dat de makkelijkste oplossing toch is om het proef ondervindelijk vast te stellen waar dan de helft van de film is (met virtdub). Daar ben je dan mischien een half uur mee bezig (direct stream-copy van virt.dub rules)

Vervolg oorspronkelijke reactie:
-------------------------------
En je moet dus juist geen VBR gebruiken voor audio in AVI-files (zie mijn reactie hierboven)


reactie aanvulling:
best wel vaag, wijzig ik bijna m'n hele reactie, komt er niet onder te staan dat ik 'm aan heb zitten passen. Pas ik daarna een spatie aan na een smiley (komt anders niet goed op het scherm), komt er wel onder te staan dat ik 'm gewijzigd heb

[scorpionv]

Op woensdag 27 juni 2001 13:33 schreef TD-er het volgende:
Je kunt toch gewoon kijken hoeveel frames de film totaal is (# frames/sec is constant)
dan pak je de zakjapanner en deel je dat aantal door 2 (eventueel afronden naar dichtst bijzijnde keyframe)
dan moet het goed gaan
En je moet dus juist geen VBR gebruiken voor audio in AVI-files (zie mijn reactie hierboven)

Ik zal je ff schokkend nieuws meegeven, een AVI video stream zelf gebruikt ook al VBR. Daar gaat het juist om in deze hele thread. Je kunt dus niet door 2 delen met je zakjapanner. Die tip van mij voor VBR audio heeft een simpele reden, Lame VBR audio van (gemiddeld) 128 kbits is al beter dan CBR audio van 192 kbit. Simpelweg omdat het programma zelf bepaalt hoeveel bitrate het nodig heeft.

[scorpionv]

Op woensdag 27 juni 2001 13:33 schreef TD-er het volgende:
Vervolg oorspronkelijke reactie:
-------------------------------
En je moet dus juist geen VBR gebruiken voor audio in AVI-files (zie mijn reactie hierboven)

Waarom dan niet? Overtuig me, ik doe het altijd en het werkt geweldig. Trouwens alle gerespecteerde ripgroepen doen het ook (niet altijd maar wel vaak).

[Majestic]

Het is dus al gelukt, gewoon een aantal keer proberen met Vdub, nu netjes 2 files van 700 MB en netjes op een scene wisseling, bedankt voor de hulp en ik hoop dat jullie de discussie over VBR mp3's kunnen voortzetten in dit topic.

Het geluid in deze film (Vertical Limit) is trouwens ook met de lame encoder gecodeerd, ik moet zeggen klinkt stukken beter dan die crappy FlaskMPEG build-in Mp3 encoder.

[scorpionv]

Op woensdag 27 juni 2001 13:48 schreef Majestic het volgende:
Het is dus al gelukt, gewoon een aantal keer proberen met Vdub, nu netjes 2 files van 700 MB en netjes op een scene wisseling, bedankt voor de hulp en ik hoop dat jullie de discussie over VBR mp3's kunnen voortzetten in dit topic.

Okay, klasse! Remember, volgende keer de audio ook op VBR doen! Scheelt ruimte en kwaliteit.

[Majestic]

Op woensdag 27 juni 2001 13:49 schreef scorpionv het volgende:

[..]

Okay, klasse! Remember, volgende keer de audio ook op VBR doen! Scheelt ruimte en kwaliteit.

Zal ik zeker doen ! hou ik een aantal mb'tjes over als spelingsruimte.

[TD-er]

bedankt voor de hulp en ik hoop dat jullie de discussie over VBR mp3's kunnen voortzetten in dit topic.

Nou, 's goed

Probeer met VBR maar eens een scene te encoden waarin je vrij statisch geluid hebt (bijv synthesiser muziek) of iets met veel ruis (zaagmachine oid)
Dat is voor MP3 vrij lastig te comprimeren. Wanneer je dan VBR gebruikt, zal de compressor proberen het geluid zo goed mogelijk laten klinken en dus meer bitjes nodig hebben. Nu is er wel een kleine buffer die kortstondige schommelingen goed kan opvangen (het bitreservoir) maar een langer stukje gaat toch net ff wat meer afwijken van de ingestelde bitrate (bijv begintune van de X-files)
Dan zul je zien dat het meteen daarna niet meer synchroon loopt.
Dan krijg je zo'n "ik kijk duitsland 1-2-3 gevoel" wanneer je naar de film kijkt (gelukkig heb je nog wel een groot aantal stemmen voor alle personen )

[scorpionv]

Sorry dat verhaal gaat niet op.
Je gooit verder 2 dingen door elkaar:
1. In zeldzame gevallen kan een VBR file net zo groot worden als een CBR, door oorzaken zoals jij zegt; veel ruis etc. Dit komt doordat de codec dan telkens de bitrate gebruikt die als maximum is opgegeven.
2. Synchronisatieproblemen hebben met het bovenstaande niets te maken. Een WAV is opgebouwd uit een zooitje frames, MP3 encodeert die frames netjes, EN WERKT OOK WEER MET FRAMES. Het maakt dus geen bal uit hoe groot een frame is, het enige wat de afspeelapparatuur doet is bijv 25 frames/seconde afspelen. Of die 25 frames nu 10 KB of 1 MB innemen boeit de speler niet.

[TD-er]

een stukje van de site van Virtualdub (dedged-up old news)
Dit was geschreven naar aanleiding van een aangepaste versie van virtualdub, waarin VBR wel mogelijk was voor Audio.

The equation that determines audio synchronization in an AVI file is time = audio_sample * block_size / average_bytes_per_second , with block_size and average_bytes_per_second being constant over the entire AVI file. AVI does support VBR streams, but as the Canopus AVI problem showed, the dwSampleSize=0 value doesn't work for audio streams (see below). Couple that with the fact that for the Fraunhofer MP3 format, block_size = 1 byte per sample, and you can see a small problem: AVI forces a rigid relationship between bytes and time. This formula is also the only relationship -- the placement of audio blocks in the file relative to video blocks, or interleaving, makes absolutely no difference in audio sync, and this why "audio skew correction" is the only setting in VirtualDub's audio menu that makes a difference. Yes, you can have VBR audio in an AVI file, and it will play. You'll also find that the greater degree of VBR used, the worse the audio sync can get in local areas. Windows Media Player is especially sensitive to fast variation of bitrate, and you can end up with variations in video playback speed as a side effect of the VBR. I think you can see now why I've not added the ability to mux VBR audio into the mainline codebase. Please do not ask me for this feature, because I'm not going to add it.

Hierna heeft 'ie 't nog over MP-3 in AVI-files in het algemeen....

Sharp observers will point out that MPEG layer III audio is inherently VBR to some extent. This is, in fact, the key to realizing how bad of hack MP3-in-AVI is. MP3 has three features that make it difficult to use in AVI:


- Bitrates can be switched on the fly, thus modifying the frame size, since frames are always 1152 samples (MPEG-1) or 576 samples (MPEG-2).
- To hit an exact bitrate at 44.1KHz, the padding bit is toggled periodically, adding or subtracting a single byte off the size of each frame.
- Unused space in a frame can be used by later ones. This is called the "bit reservoir."

Dit is waarom ik denk dat je beter geen VBR-MP-3's kunt gebruiken in een AVI-file.

[scorpionv]

Ai, je hebt iig voor een deel gelijk. Het schijnt iets dieper te zitten dan puur frame-frame syncen. Maar in NanDUB, (VirtualDUB hack) zit dan toch wel de optie voor VBR audio. En ik heb al veel films gecodeerd maar nog nooit problemen gehad met de audio-sync door VBR. Dus ik denk dat het wel losloopt.

[TD-er]

Ik al wel, vandaar ook dat ik met het voorbeeld van de X-files aankwam.

[GarBaGe]

Met Fair Use codeer ik altijd voor 1300 MB bestanden ipv 1400. Verschil in kwaliteit is verwaarloosbaar, maar knipt net ff iets handiger.