So Bad It's Good FoRuM :: View topic - Ripping/encoding/releasing Q & A Prt. III

junkboy wrote:

ffmpegsource in vdubmod for mkv screens.

Slayer wrote:

Denoise this or not?

http://www.mediafire.com/?p3docxbfrgfn3o0

Quote:

Thanks to tebasuna51 for moderating the bug/improvement list, and for investigating the "duplicate frame" stuff for seamless branching Blu-Rays. I didn't know that overlapping AC3 and DTS frames were actually bit-wise identical! With this information eac3to can now discard such frames immediately, which means that it's no longer necessary to do a 2nd pass for seamless branching Blu-Rays to fix audio overlaps. This new logic should also avoid any audio glitches at the seamless branching edit points - because simply no edits are necessary, anymore, at all. Please note that this only applies to AC3 and DTS (and DTS-HD/MA) tracks. It does not apply to LPCM and TrueHD tracks. However, overlaps with LPCM and TrueHD tracks are rather small, so overlap editing is often not necessary for such tracks, anyway. The new logic also only works if the overlapping AC3 and DTS frames are truely identical. They have been with the 2 Blu-Rays I've tested with. But I don't know for sure if that's the case for *all* seamless branching Blu-Rays. So there's a chance the old overlap logic might still be used for some Blu-Rays.

It seems that mono TrueHD decoding is currently broken when using libav/ffmpeg decoding, but I'm not 100% sure because I only have one such sample and it's pretty short. Maybe you guys can double check (and provide me with a longer sample)? This looks like a libav/ffmpeg bug to me, though, if it's really a bug at all. At least Brave TrueHD decoding seems to be working fine now.

Please note that although eac3to now supports parsing, demuxing and core-extraction for Blu-Ray primary E-AC3 tracks, currently no decoder is available which can decode the full audio information with all 6.1/7.1 channels. Currently only the AC3 core can be decoded which results in 5.1 output only.

Quote:

eac3to v3.27 released

http://madshi.net/eac3to.zip

Code:

* fixed: raw processing cut away 16 samples sometimes

I'll probably be gone for a while now.

telmoMRC wrote:

tas a fazer algo mal reve os passos aqui tens o meu x264 http://www.sendspace.com/file/i8gid8

Quote:

Download

Here is >>>> dither-1.22.1.zip <<<<. The package includes:

dither 1.22.1 plug-in and scripts
dfttest 1.9.2 (mod16)
MVTools 2.6.0.5 (mod16)
avstp.dll 1.0.1

[url="http://manao4.free.fr/"]Masktools 2 a48[/url] or above is now required. Previous Masktools versions will silently fail and cause the greenish screen of death. Please update your Masktools before installing the Dither script.

All these plug-ins include the -Vit- threading fixes.

What is it?

Dither is a package including several scripts and avisynth plug-ins. Some of them are modification of existing ones. I primarily wrote the Dither tools to fight [url="http://en.wikipedia.org/wiki/Color_banding"]color banding[/url] during denoising in an unusual way. But Dither can perform various operations :

Recover the high bitdepth data possibly contained in a noisy clip. This can be seen as an "inverse-dithering" operation. In computer graphics, people usually use a gaussian filter to turn halftones into shades of grey. We'll use denoisers here.

Dither a high bitdepth picture into a standard YV12. The picture may have been obtained with the inverse-dithering operation, the combination could be called "transdithering".

Smooth fine gradients to remove colorbanding, resulting in a high bitdepth picture which can be dithered later.

Performing basic operations (masking, curves...) on high bitdepth pictures, as they cannot be manipulated safely with conventional avisynth filters.

Why should I use it?

Because denoising and lossy compression can easily make colorbanding appear. By transdithering, it is possible to recover original gradients better than using a filter + GradFun2DB(mod). Moreover, classic error-diffusion dithering algorithms require a high bitrate during encoding, otherwise color banding appears again. Dither offers an [url="http://en.wikipedia.org/wiki/Ordered_dithering"]ordered dithering[/url] (Bayer matrix), which is more resilient to data compression.

How can I use it?

The simplest way to transdither a relatively clean source, using the modified dfttest:

Code:

dfttest (sigma=2, lsb=true)
DitherPost ()

You can add a SmoothGrad() call between both statements to remove colorbanding present in the source. And because dfttest is a spatio-temporal filter, it would be better to also use [url="http://forum.doom9.org/showthread.php?t=147676"]motion compensation[/url] to increase filter accuracy and prevent ghosting.

For an already denoised source, use

Code:

GradFun3 ()

GradFun3 is intended to replace GradFun2DB(mod). Actually it works on the same principle and does almost the same things, but it uses ordered dithering by default, which is better for compressibility.

Author:	Slayer [ Thu Jan 03, 2013 10:02 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
OK, well, I don't mind really, I was just asking for opinions. So if anyone thinks denoising would be nice, let me know. (It's a VHS transfer, btw.) New question: how can I take screenshots of an mkv file?

Author:	junkboy [ Thu Jan 03, 2013 11:28 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
The sample looks more like an old, beat-up master than it does a VHS->DVD. One way of denoising it would be to calm the dancing grain and then remove the dirt/spots. If you choose to denoise it another way, watch out for it 'swimming'. ffmpegsource in vdubmod for mkv screens.

Author:	Slayer [ Fri Jan 04, 2013 2:32 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Thx, I'll check out the denoising and see if I like it better. About the source: after the movie, a message shows up about the licensing of "the picture contained in this videocassette". So that reeks of VHS to me. This junkboy wrote: ffmpegsource in vdubmod for mkv screens. I don't understand. When I want to open the mkv, it starts parsing it and then vdubmod crashes.

Author:	max_cady [ Fri Jan 04, 2013 4:03 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
FFVideoSource("my.movie.mkv")

Author:	Slayer [ Fri Jan 04, 2013 2:31 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
OK, so I have to index a file, using Avisytnh plugins? Isn't this a very lengthy way to simply take a screenie? I solved my issue now by screenshotting the Youtube version of the film, but it sounds overly complicated to me just to take a picture of an mkv file (but maybe I simply don't udnerstand, that is very well possible).

So Bad It's Good FoRuM https://sbig.dead-donkey.com/

Ripping/encoding/releasing Q & A Prt. III https://sbig.dead-donkey.com/viewtopic.php?f=31&t=17215	Page 34 of 37

Author:	junkboy [ Fri Jan 04, 2013 3:22 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Before FFMS2 can open a file, it must be indexed first so that keyframe/sample positions are known and seeking is easily accomplished. It should only take a few seconds to index, and opening an .avs containing FFVideoSource("my.movie.mkv") in vdubmod is hardly taxing.

Author:	Slayer [ Fri Jan 04, 2013 3:39 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Yes, I read that. It is less complicated than I thought, but still a bit more than with avi files. Prob solved, thanks all.

Author:	zacharias [ Fri Jan 04, 2013 9:06 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Slayer wrote: Denoise this or not? http://www.mediafire.com/?p3docxbfrgfn3o0 maybe jsut the minimum at all. i rather see grain tha faggot a denoised picture kudos

Author:	max_cady [ Sat Jan 05, 2013 4:46 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
eac3to v3.25 released. Code: http://forum.doom9.org/showthread.php?p=1608610#post1608610 v3.25 * fixed: option "-down6" didn't handle 6.1 tracks properly * fixed: option "-down6" for 7.1 content lowered side channels in volume * fixed: 6.1 DTS/E-AC3 libav decoding resulted in incorrect 70f channel mask * fixed: a couple of funny AC3 channel configs resulted in swapped channels * fixed: option "-check" failed for SRT subtitles * fixed: MKV tracks without language information didn't default to "English" * fixed: 16bit MLP decoding didn't work at all * fixed: DTS 2.1 decoding had empty sub channel when using ArcSoft decoder * fixed: muxing h264 video streams without VUI eventually crashed * fixed: SMPTE 302M 20bit PCM tracks didn't extract properly * improved AC3 seamless branching handling by detection of identical frames * improved DTS seamless branching handling by detection of identical frames * updated to latest ffmpeg/libav revision * added support for libav DTS 6.1 and 7.1 decoding (only in core, no DTS-HD) * added support for encoding all AC3 channel configurations * added support for demuxing Blu-Ray primary E-AC3 tracks (AC3 core) * libav is now the default decoder for AC3 and E-AC3 * option "-down2" is now deprecated, but still supported * option "-downDpl" mixes down to Dolby Pro Logic II * option "-downStereo" mixes down to standard stereo * added support for mixing any channel configuration to stereo/DPL * DPL downmixing doesn't lower volume, anymore (except when clipping occurs) * editing audio tracks by adding silence is now less restrictive * trying to mux right eye stream to MKV errors out now, instead of crashing * doing "eac3to 1) movie.mkv" for 3D BDs now properly skips right eye stream * FLAC encoding is now done with optimized block sizes for "LossyWAV" files * encoder bitdepth for lossy DTS tracks is no longer displayed * option "-test" no longer checks mkvtoolnix Quote: Thanks to tebasuna51 for moderating the bug/improvement list, and for investigating the "duplicate frame" stuff for seamless branching Blu-Rays. I didn't know that overlapping AC3 and DTS frames were actually bit-wise identical! With this information eac3to can now discard such frames immediately, which means that it's no longer necessary to do a 2nd pass for seamless branching Blu-Rays to fix audio overlaps. This new logic should also avoid any audio glitches at the seamless branching edit points - because simply no edits are necessary, anymore, at all. Please note that this only applies to AC3 and DTS (and DTS-HD/MA) tracks. It does not apply to LPCM and TrueHD tracks. However, overlaps with LPCM and TrueHD tracks are rather small, so overlap editing is often not necessary for such tracks, anyway. The new logic also only works if the overlapping AC3 and DTS frames are truely identical. They have been with the 2 Blu-Rays I've tested with. But I don't know for sure if that's the case for all seamless branching Blu-Rays. So there's a chance the old overlap logic might still be used for some Blu-Rays. It seems that mono TrueHD decoding is currently broken when using libav/ffmpeg decoding, but I'm not 100% sure because I only have one such sample and it's pretty short. Maybe you guys can double check (and provide me with a longer sample)? This looks like a libav/ffmpeg bug to me, though, if it's really a bug at all. At least Brave TrueHD decoding seems to be working fine now. Please note that although eac3to now supports parsing, demuxing and core-extraction for Blu-Ray primary E-AC3 tracks, currently no decoder is available which can decode the full audio information with all 6.1/7.1 channels. Currently only the AC3 core can be decoded which results in 5.1 output only.

Author:	telmoMRC [ Sun Jan 06, 2013 12:35 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
ohh yes its about time ehehh

Author:	max_cady [ Sun Jan 06, 2013 10:47 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Already eac3to v3.27 released. eac3to v3.26 released * fixed: downmixing of less than 6 channels to stereo failed * patched libav AC3 decoder to properly decode high frequencies * added support for floating point volume changes (e.g. -0.5db) * dialnorm is no longer removed from DTS-HD tracks (didn't work, anyway) Quote: eac3to v3.27 released http://madshi.net/eac3to.zip Code: * fixed: raw processing cut away 16 samples sometimes I'll probably be gone for a while now.

Author:	telmoMRC [ Mon Jan 07, 2013 4:07 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
again

Author:	Slayer [ Wed Jan 16, 2013 4:09 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
I can't seem to make a working d2v out of the VOBs I ripped. GK simply says it's invalid. Any thoughts?

Author:	junkboy [ Wed Jan 16, 2013 8:06 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
You've not deleted or changed the location of the VOB's have you?

Author:	flyingsheepcannon [ Thu Jun 27, 2013 3:23 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
my girl's parents bought this box that hooks up to a VCR (via the component yellow, white, red cords) and plugs into your computer with a USB so you can "convert" VHS to DVD. Well the program that came with it is a total piece of shiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit. Do you guys know if another program would work for it?

Author:	^Rogue^ [ Tue Aug 27, 2013 2:54 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Looks like you dgmpegdec is missing. It's usually somewhere in the GKnot folder.

Author:	Slayer [ Tue Aug 27, 2013 4:42 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
So I need to import it in avs? Like this: Import("C:\Program Files\GordianKnot\AviSynthPlugins\GradFun2DBmod.v1.5.avs")

Author:	^Rogue^ [ Tue Aug 27, 2013 7:21 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Yeah, give it a try.

Author:	Slayer [ Wed Jan 16, 2013 9:01 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Mmm, prob solved. I tried remaking the d2v for yet one more time and it worked now.

Author:	telmoMRC [ Tue Jan 22, 2013 9:05 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
i have a FS bluray after crop it give me 1462x1080 (1.354:1) so te rigth resolution will be 972x720(1.35) ?

Author:	max_cady [ Tue Jan 22, 2013 9:10 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
1462/1080=1.353703703703704 1.353703703703704x720=974.6666666666669 So using 976x720 better.

Author:	telmoMRC [ Tue Jan 22, 2013 11:32 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III

Author:	zacharias [ Sun Jan 27, 2013 4:56 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
WTF?!?! something peculiar happened. i got this final ratefactor even when i incresed output file sized... previously for the same fil and with lower outputsize i got a higher ratefactor (LOL?) is it a x264 bug or something? can someone upload me his x264 file for me please? thanks in advanced.

Author:	telmoMRC [ Mon Jan 28, 2013 3:39 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
tas a fazer algo mal reve os passos aqui tens o meu x264 http://www.sendspace.com/file/i8gid8

Author:	zacharias [ Mon Jan 28, 2013 9:27 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
telmoMRC wrote: tas a fazer algo mal reve os passos aqui tens o meu x264 http://www.sendspace.com/file/i8gid8 na, man. everything is just da same. since i made a 1/11 dvd for a 24min video and a 1/12 for the same file. encode was just perfect. but idk. thats da same version i had as far as i could tell. thanks anyways. could it be the target filesize? just wodering. obrigad?o mano!

Author:	max_cady [ Mon Feb 04, 2013 5:51 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Quote: Download Here is >>>> dither-1.22.1.zip <<<<. The package includes: dither 1.22.1 plug-in and scripts dfttest 1.9.2 (mod16) MVTools 2.6.0.5 (mod16) avstp.dll 1.0.1 [url="http://manao4.free.fr/"]Masktools 2 a48[/url] or above is now required. Previous Masktools versions will silently fail and cause the greenish screen of death. Please update your Masktools before installing the Dither script. All these plug-ins include the -Vit- threading fixes. What is it? Dither is a package including several scripts and avisynth plug-ins. Some of them are modification of existing ones. I primarily wrote the Dither tools to fight [url="http://en.wikipedia.org/wiki/Color_banding"]color banding[/url] during denoising in an unusual way. But Dither can perform various operations : Recover the high bitdepth data possibly contained in a noisy clip. This can be seen as an "inverse-dithering" operation. In computer graphics, people usually use a gaussian filter to turn halftones into shades of grey. We'll use denoisers here. Dither a high bitdepth picture into a standard YV12. The picture may have been obtained with the inverse-dithering operation, the combination could be called "transdithering". Smooth fine gradients to remove colorbanding, resulting in a high bitdepth picture which can be dithered later. Performing basic operations (masking, curves...) on high bitdepth pictures, as they cannot be manipulated safely with conventional avisynth filters. Why should I use it? Because denoising and lossy compression can easily make colorbanding appear. By transdithering, it is possible to recover original gradients better than using a filter + GradFun2DB(mod). Moreover, classic error-diffusion dithering algorithms require a high bitrate during encoding, otherwise color banding appears again. Dither offers an [url="http://en.wikipedia.org/wiki/Ordered_dithering"]ordered dithering[/url] (Bayer matrix), which is more resilient to data compression. How can I use it? The simplest way to transdither a relatively clean source, using the modified dfttest: Code: dfttest (sigma=2, lsb=true) DitherPost () You can add a SmoothGrad() call between both statements to remove colorbanding present in the source. And because dfttest is a spatio-temporal filter, it would be better to also use [url="http://forum.doom9.org/showthread.php?t=147676"]motion compensation[/url] to increase filter accuracy and prevent ghosting. For an already denoised source, use Code: GradFun3 () GradFun3 is intended to replace GradFun2DB(mod). Actually it works on the same principle and does almost the same things, but it uses ordered dithering by default, which is better for compressibility.

Author:	^Rogue^ [ Thu Jun 27, 2013 9:07 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Virtualdubmod should work. Old school and still good.

Author:	Slayer [ Mon Aug 26, 2013 11:36 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Any good programs to use for cutting VOBs? I used to use Chopper XP, but I have Win8 now and can't get it to work (it keeps saying that vob files aren't supported). So if anyone knows of an equivalent of Chopper XP which works in Win8, I'd love to hear about it.

Author:	Slayer [ Tue Aug 27, 2013 10:54 am ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Anybody know how to solve this? I want to rip a sample, but it won't open the mpegsource? Wtf?

Author:	junkboy [ Tue Aug 27, 2013 7:30 pm ]
Post subject:	Re: Ripping/encoding/releasing Q & A Prt. III
Yeah, you import GradFun2DBmod, but (as ^Rogue^ pointed out) you're missing DGMPGDec if you're getting that error message. Put DGDecode.dll in your avisynth plugins folder.

Page 34 of 37	All times are UTC + 1 hour [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group https://www.phpbb.com/