View Profile
View Forum Posts
Private Message
Hi,
I resolved to start all over again the conversion of those 12 (!) drum lessons DVDs for a friend (of whom I spend an awful lot of time trying to satisfy each and every demand *sigh* {side question : is the grammar correct here ?}). I first requested assistance for one of them here.
So I would like to know :
1) if I correctly figured the "source type" settings for each DVD set ;
2) how to treat the different types of footage for "BG 2009", disc 2 ;
3) how to correct the colors for GH 2002 & GH 2006 ;
4) if any other treatment(s) would be required, from the look of the samples.
Plus a general question : when are the "Mpeg Deblocking" and "Colour correction" filters required/recommanded ? (The second one being selected by default in MeGUI.)
The general purpose is to transcode those videos as compact MKV files that could be read on small devices like a "tactil tablet", and/or on a computer ; I'm aiming at a subtantial level of compression while retaining a good quality (so that an untrained/uneducated eye would think it's identical to the source, even though it's not quite the case), so I settled on these general encoding parameters :
CRF=24, preset=slow (perhaps an additional --bframes=5 for a few of them), profile High@L3.1.
Detail :
– BG 2009 > 2 DVD-5 discs, 16:9
The "lessons" footage seems to be progressive (so at first I treated everything as such and used no special source treatment), but then on the second disc there are extra features with apparently different patterns. I'm wondering if I should : just treat everything as progressive (anyway the extra features are of rather poor quality), or encode the extra features separately with specific treatment, or if it's possible to still encode the whole disc as one video (all parts being in one single "VTS") while applying different treatment to different zones.
Samples :
http://www.mediafire.com/watch/kyjkbitkvblyaaw/BG2009_2_VTS_01_1_extrait1.demuxed.m2v
= lessons -- Apparently progressive footage (MeGUI's script creator analysis says the whole video is progressive, but as I've learned it only analyses a small part)
http://www.mediafire.com/watch/w80vh4t31ipxxwd/BG2009_2_VTS_01_1_extrait2.demuxed.m2v
= extra feature 1 -- ## the .d2v opens a completely different part than the intended sample, see below
http://www.mediafire.com/watch/qq7zjvl479fdj1o/BG2009_2_VTS_01_1_extrait3.demuxed.m2v
= extra feature 2 -- MeGUI's analysis says "M-in-5 decimation required", suggests "Tritical decimate" > What does it mean ? What is the original framerate ?
http://www.mediafire.com/watch/etyn2qjbkz6gorl/BG2009_2_VTS_01_1_extrait4.demuxed.m2v
= extra feature 3 -- MeGUI's analysis says "M-in-5 decimation required", suggests "Tritical decimate"
http://www.mediafire.com/watch/kyta52bbebh2d7j/BG2009_2_VTS_01_1_extrait5.demuxed.m2v
= extra feature 4 -- MeGUI's analysis says "M-in-5 decimation required", suggests "Tritical decimate"
http://www.mediafire.com/watch/qh7118c4q82u6cr/BG2009_2_VTS_01_1_extrait6.demuxed.m2v
= extra feature 4 -- MeGUI's analysis says "M-in-5 decimation required", suggests "Tritical decimate"
## One weird thing here is that some of the d2v index files (samples 1 & 2), when opened in MeGUI, don't correspond to the m2v samples created at the same time. It may be related to the fact that the main title contains several "PGCs", which caused a huge A/V desynchronization issue when I first tried to encode BG 2014, which has a similar structure (I solved this with PGCDemux), though it didn't affect BG 2009 in the same way (no sync issue).
– BG 2015 > 1 DVD-9 disc, 16:9
This one seems to be all progressive footage, but encoded as interlaced. I encoded it as is (is that correct, even when the video is encoded as interlaced ?), no source treatment and anamorphic 720x480 16:9.
Sample : http://www.mediafire.com/watch/us4zg5dfddmahv2/BG2015_VTS_01_1_extrait.demuxed.m2v
– JM 2007 > 2 DVD-5 discs, 16:9 picture in a 4:3 frame
This one seems to be truly interlaced footage. I deinterlaced with QTGMC "medium", cropped and resized to 640x360.
Sample : http://www.mediafire.com/watch/c7vsduecjf87z4p/JM2007_1_VTS_01_1_extrait.demuxed.m2vCode:Vid = MPEG2Source("E:\FullDisc\Jojo Mayer - 2007 - Secret weapons for the modern drummer - 1. A guide to hand technique - 1A.d2v") VidDeint = Vid.QTGMC(Preset="Medium") VidResize = VidDeint.crop(0, 60, 0, -60).LanczosResize(640,360) Aud = NicAC3Source("E:\FullDisc\Jojo Mayer - 2007 - Secret weapons for the modern drummer - 1. A guide to hand technique - 1A T80 2_0ch 192Kbps DELAY 0ms.ac3") Mix = AudioDub(VidResize, Aud) Return(Mix)
– JM 2014 > 3 DVD-5 discs, 16:9
This one seems to be progressive footage encoded as progressive. I encoded it as is, no source treatment and anamorphic 720x480 16:9.
Sample : http://www.mediafire.com/watch/eh139b43sbhi1c7/JM2014_1_VTS_01_1_extrait.demuxed.m2v
– HH 2006 : 1 DVD-5 disc, 4:3
Cf. the previous thread. Truly interlaced footage, used QTGMC "medium", resized to 640x480.
Samples (same as the previous thread) :
http://www.mediafire.com/watch/kg21oy3of6nxby3/Horacio_Hernandez_VTS_02_1_16m28-17m20.demuxed.m2v
http://www.mediafire.com/watch/j43ai0c8lalprsw/Horacio_Hernandez_VTS_02_1_1h12m28-1h13...15.demuxed.m2v
– GH 2002 & GH 2006 > 3 DVD-5 discs, 4:3
This one seems to be truly interlaced. Haven't attempted to convert it yet. Has a color problem that I was struggling to correct before I let it lie at the end of July... The picture seems very dull, with desaturated colors and a weak contrast.
I tried to use the "Tweak" filter, tried to fine-tune it using AvsPmod, couldn't find the "sweet spot" (and my screen, a Iiyama 24" ProLite B2409HDS with TN panel, while very nice for general purposes, might not be ideal for an accurate work on colour -- I actually bought it from a plastician artist who was frustrated with it, and who then bought a more pro-oriented screen, at least twice as expensive) :
Samples :Code:global MeGUI_darx = 16 global MeGUI_dary = 9 Vid = MPEG2Source("E:\FullDisc\Gavin Harrison - Rhythmic Visions (2002) - Introduction.d2v") VidDeint = Vid.QTGMC(Preset="Medium") VidResize = VidDeint.LanczosResize(640,480).Tweak(sat=1.2, cont=1.1) # probably too strong Aud = NicAC3Source("E:\FullDisc\Gavin Harrison - Rhythmic Visions (2002) - Introduction T80 2_0ch 448Kbps DELAY 0ms.ac3") Mix = AudioDub(VidResize, Aud) Return(Mix)
http://www.mediafire.com/watch/6btm5f2wscwr8ke/GH2002_VTS_02_1_extrait.demuxed.m2v
http://www.mediafire.com/watch/j6valk6ndn3f453/GH2006_A_VTS_02_1_extrait.demuxed.m2v
Thanks !
+ Reply to Thread
Results 1 to 30 of 36
-
Last edited by abolibibelot; 8th Oct 2015 at 17:09.
-
This is a situation where I would choose speed over pristine quality. I would just toss everything into handbrake and be done with it.
-
But you still have to select filters in Handbrake, it just has less options. And the encoding time would be roughly the same (unless QTGMC is used as a deinterlacer in MeGUI).
Actually it seems like the owner of those DVDs (this friend's drum teacher -- said friend brought me the teacher's USB drive to put the encoded files on it) already tried to convert them using Handbrake (resulting files are on the USB drive) and had funky results with some of them (incomplete video, incorrect cropping, wrong aspect ratio, interlaced footage encoded as progressive with a low bitrate making it look terrible...), so I figured if I'm spending time on it, I'd rather be doing it right. -
You're a really good friend. Can't fault you for that.
-
I can't look at the samples closely now, but I will later. However.....Originally Posted by abolibibelot
When it comes to PAL video it's generally easy enough to work out what's required by looking at it in MeGUI's preview. The analysis tends to be more accurate if the video has a lot of motion. For the "Horacio Hernandez VTS_02_1 16m28-17m20.demuxed" sample you linked to in the other thread, MeGUI thinks it's "Hybrid film, mostly interlaced" and wants to apply IVTC, but what it adds to the script would normally be used to de-interlace the interlaced parts of NTSC video, and convert the film parts to 29.970 after applying IVTC. It doesn't ever apply to PAL that I'm aware of.
Likewise"M-in-5 decimation required", and "Tritical decimate" would probably never apply to PAL. I've seen MeGUI come to that conclusion myself, but it's invariably wrong. At one stage I asked the guy who maintains MeGUI about it wanting to apply NTSC type de-interlacing to PAL video but I'm not sure he understood what I was saying. If you don't mind, I might use your samples to report the problem again at some stage in the future.
Your video is bound to be interlaced, or partly interlaced. Just use QTGMC() or "Yadif with Bob". Sometimes the fields of progressive video can be out of order and as a result it looks interlaced in MeGUI's preview, so try "Yadif with bob" first. If you can then step through the frames and they're unique (not repeated) and without interlacing jaggies, the video is interlaced. If each frame is repeated it's probably progressive, and simple field matching should fix it (you won't need to also de-interlace):
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
tfm()
And of course if you don't see any interlacing jaggies when stepping through the frames (before applying filtering) then it's likely to be progressive.
They're the three most likely PAL types. There's other possibilities such as "euro pulldown" to convert film to PAL, but MeGUI's analysis will never get that right. It's possible for PAL video to be a combination of interlaced and progressive, in which case I'd use QTGMC(). The progressive parts will end up 50fps with every frame repeated and the interlaced parts will be de-interlaced to 50fps progressive with unique frames. Or use QTGMC().SelectEven() if it's mostly progressive and you want a 25fps output.
For your indexing problem with DGIndex, try opening the DVD or ripped DVD files with DVDShrink. Set it's target output size in preferences to DVD9 or larger so it won't try to shrink. Click on the Re-Author button. Drag each title you want to encode from the right pane to the left pane (there's a button above the left pane for editing titles if you want to). You can drag a single title across multiple times and edit it down to specific sections if need be, but usually there's one title per episode or one title for the movie. Use the backup function to create a new backup copy of the DVD. The new copy will contain a single set of vob files for each title you dragged across. Open the first vob file in the set with MeGUI and index it. You shouldn't have any problems indexing a properly prepared DVD.
Out of curiosity..... why are you using the OneClick encoder? Not that I'm saying you shouldn't, but given you're preparing scripts and modifying them manually, wouldn't it be better to use the script creator to create them, load each script into the video section and then use AutoEncode to give you the final output? Mostly I just add a script to the queue for encoding, encode it, then mux the output video with the audio using MKVMergeGUI myself.Last edited by hello_hello; 8th Oct 2015 at 23:58.
-
I was having a play with the "Horacio Hernandez VTS_02_1 1h12m28-1h13m15.demuxed" sample from the other thread and noticed something I've not quite seen before. Someone else may know. Is this just bad encoding? I'm sure the video is purely interlaced, but every so often there's noticeable "interlaced" blocking where's there's fast movement. Like this (look at the drum stick in his right hand):
De-interlacing doesn't fix it as such. It just de-interlaces it.
-
I checked sample one, http://www.mediafire.com/watch/kyjkbitkvblyaaw/BG2009_2_VTS_01_1_extrait1.demuxed.m2v
it is progressive, marked as interlace, so encode it as progressive
second sample http://www.mediafire.com/watch/w80vh4t31ipxxwd/BG2009_2_VTS_01_1_extrait2.demuxed.m2v has 5 frames progressive and sixth one is duplicated, not sure if there is applied once in a while that dropped frame, video was probably transfered from 25fps to 29.97 fps just duplicating every fifth frame, so use that tritical decimate or some other decimal function to get 25fps back from it, -
Apparently they're all NTSC (720x480, 29.97 FPS).Originally Posted by hello_hello
Again, it's NTSC. What did it add when you tried ? (In previous, unrelated threads, there could be discrepancies between what another member reported and what I experienced, with regards to that analysis -- which only analyses a small portion of the video anyway.)The analysis tends to be more accurate if the video has a lot of motion. For the "Horacio Hernandez VTS_02_1 16m28-17m20.demuxed" sample you linked to in the other thread, MeGUI thinks it's "Hybrid film, mostly interlaced" and wants to apply IVTC, but what it adds to the script would normally be used to de-interlace the interlaced parts of NTSC video, and convert the film parts to 29.970 after applying IVTC. It doesn't ever apply to PAL that I'm aware of.
I don't mind, but it's not PAL ! :^pLikewise"M-in-5 decimation required", and "Tritical decimate" would probably never apply to PAL. I've seen MeGUI come to that conclusion myself, but it's invariably wrong. At one stage I asked the guy who maintains MeGUI about it wanting to apply NTSC type de-interlacing to PAL video but I'm not sure he understood what I was saying. If you don't mind, I might use your samples to report the problem again at some stage in the future.
It's probably what I experienced here (but not relevant in this case).Your video is bound to be interlaced, or partly interlaced. Just use QTGMC() or "Yadif with Bob". Sometimes the fields of progressive video can be out of order and as a result it looks interlaced in MeGUI's preview
Yes, I learned that method in the aforementioned thread, it just seems a little weird to apply a given treatment which may or may not be required in order to determine which treatment is actually required...so try "Yadif with bob" first. If you can then step through the frames and they're unique (not repeated) and without interlacing jaggies, the video is interlaced.
So this apply only when the fields are out of order ?If each frame is repeated it's probably progressive, and simple field matching should fix it (you won't need to also de-interlace):
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
tfm()
And then no filtering at all is required to get a proper progressive re-encode ?And of course if you don't see any interlacing jaggies when stepping through the frames (before applying filtering) then it's likely to be progressive.
Thanks for this thorough overview, but again, all NTSC in this particular case... (I guess those are import DVDs.)They're the three most likely PAL types. There's other possibilities such as "euro pulldown" to convert film to PAL, but MeGUI's analysis will never get that right. It's possible for PAL video to be a combination of interlaced and progressive, in which case I'd use QTGMC(). The progressive parts will end up 50fps with every frame repeated and the interlaced parts will be de-interlaced to 50fps progressive with unique frames. Or use QTGMC().SelectEven() if it's mostly progressive and you want a 25fps output.
I already know DVDShrink, and I guess PGCDemux serves the same purpose in such a case, but I'd be interested in having a better understanding of DVD structure and how it can mess things up when it gets a little more complex.For your indexing problem with DGIndex, try opening the DVD or ripped DVD files with DVDShrink. Set it's target output size in preferences to DVD9 or larger so it won't try to shrink. Click on the Re-Author button. Drag each title you want to encode from the right pane to the left pane (there's a button above the left pane for editing titles if you want to). You can drag a single title across multiple times and edit it down to specific sections if need be, but usually there's one title per episode or one title for the movie. Use the backup function to create a new backup copy of the DVD. The new copy will contain a single set of vob files for each title you dragged across. Open the first vob file in the set with MeGUI and index it. You shouldn't have any problems indexing a properly prepared DVD.
Well, I tried it first and kinda stuck with it, for once... Otherwise, I like the convenience of setting everything (video + audio + subtitles + chapters) and then letting it run until the intended video is done, with no need for further intervention. And so far I use the script creator mostly as a guidance, considering it lacks key features (like QTGMC) and I'd like to improve my knowledge in Avisynth scripting instead of letting it do its things "under the hood" (also because it sometimes gets things wrong, as you stated above). Besides, when I tried the "AutoEncode" module (didn't go very far I'll admit), it seemed very "newbie-oriented", with for instance the default option measuring the intended file size in CD/DVD units and very basic options in general (plus how couldn't figure how to add chapters or subtitles -- well, I tried again, and indeed when "Add additional content" is checked it opens another window, "Adaptive muxer", with the relevant options, but I find it more "clunky", and it doesn't seem possible to save profiles, as with "One click encoder").Out of curiosity..... why are you using the OneClick encoder? Not that I'm saying you shouldn't, but given you're preparing scripts and modifying them manually, wouldn't it be better to use the script creator to create them, load each script into the video section and then use AutoEncode to give you the final output? Mostly I just add a script to the queue for encoding, encode it, then mux the output video with the audio using MKVMergeGUI myself.
What is the advantage of muxing the final file as a separate task ? -
OK, so in such a case no treatment is required.Originally Posted by _Al_
On a completely unrelated note : Last year I authored a DVD from a conference I had filmed, I exported the edited video (with Magix Video Deluxe) as interlaced MPEG2, but I'm pretty sure it's progressive footage (well, there was a mixture of 3 cameras : 29,970 FPS progressive MP4 from a Sanyo HD1000 video camera, 30 FPS progressive MOV from a Canon SX20 bridge camera, and then I'm not so sure, AVCHD footage from a Panasonic ZS3 which MediaInfo sees as NTSC but is 25 FPS, but it also says it has "frame doubling" and a "native" framerate of 50 FPS, if that makes any sense), yet I can see the "combing" effect on moving areas when watching it on my computer, which is not the case with that one above. Does it mean I used the wrong field order, and if so, can it cause issues of some kind ? It says "bottom field first", I think I read somewhere it was standard for DVD video -- but "BG 2009" also reports "bottom field first".
That's indeed what I noticed. Is it important in such a case to get it back to 25fps ? Does that frame duplicating add a visible jerkiness effect ? And can I still create a single MKV while treating only those extra features with a decimate filter, or it won't work because of the different framerate ?second sample http://www.mediafire.com/watch/w80vh4t31ipxxwd/BG2009_2_VTS_01_1_extrait2.demuxed.m2v has 5 frames progressive and sixth one is duplicated, not sure if there is applied once in a while that dropped frame, video was probably transfered from 25fps to 29.97 fps just duplicating every fifth frame, so use that tritical decimate or some other decimal function to get 25fps back from it, -
if you'd have wrong field order you'd know, moves would be back and forth sort of, you have something else going on
if footage is progressive only, you can make bottom field first or top field first, it does not matter
but you can also make progressive DVD (HC encoder can encode it, and muxman mux it)
BUT that footage NTSC, 25fps, native frame rate of 50fps, I have no idea what it is
last question, you have original, so you compare how it feels,
I never had to decimate, I do not do this sort of "fixing", if that clip is long you might get audio sync issues while making it back 25fps because of that drop frame, perhaps I would not bother at all, I'd just encoded it 29.97 progressive, you might notice something while camera is steady and there is some subtle pans etc., nothing like that clip, where jerkiness - handheld camcorder with zoom and fast action makes those things invisible sorta -
Maybe someone for the color issue ? (Last 2 samples.)
-
I'm a bit late returning to the thread (the real world got in the way) but I read your reply, looked at the samples again, and yes..... sorry. I'm an idiot. I have no idea why, but I had it in my head I was looking at PAL samples at the time. Maybe I was also working on something else and confused myself or maybe it was because those B/W clips earlier were PAL and I assumed without checking.Originally Posted by abolibibelot
Apparently they're all NTSC (720x480, 29.97 FPS).Originally Posted by hello_hello
So nothing I said about PAL video applies to your samples. It's not wrong. It just doesn't apply here. Sorry.
Maybe I should try playing with OneClick more myself. I know it can be configured and it'll use script templates etc but I've always looked at it more as the "under the hood" method. I've never encoded a DVD video with it myself.Originally Posted by abolibibelot
I don't even use AutoEncode much. I assume OneClick can extract chapters and subtitles for you, whereas when using AutoEncode you need to extract them yourself first and add them to the AutoEncode job. OneClick was fairly basic when I started using MeGUI and it's gone through a lot of changes, so maybe I should have another look. It may be able to replace AutoEncode with more functionality.
I guess for me muxing manually is partly habit, but I rarely re-encode audio with MeGUI these days (if I do I use foobar2000), so I use the script creator to create scripts and load them into the job queue, then manually mux the audio when it's done. But I'm often re-encoding other file types too (ie MKV, MP4, AVI) so I open the encoded video with MKVMergeGUI, add the source file (ie MKV, MP4, AVI), de-select the original video stream and remux. It cuts down on a lot of extracting and ensures the audio sync won't change. And often I remove all the studio and production company promos from the beginning, so rather than split the audio, split subtitles and chapters etc, I create a script to encode just the junk at the beginning, another to encode the rest, append the two encodes with MKVMergeGUI while adding the source file, deselect the original video stream and tell MKVMergeGUI to split the output at the point where the two encodes are appended. The idea being it gives me two new MKVs. One containing just the junk at the beginning I can then delete, and the second one containing the video I want. If there's subtitles and chapters etc they stay in the same position relative to the video so there's no reason to adjust them separately. Oh..... and the reason for encoding the video in two sections.... it ensures there's a keyframe exactly where I want to split.
Anyway.... I'll have another look at OneClick soon. -
To redeem myself I looked at a few of the samples. They were all 29.970 progressive. The first didn't require filtering while the others were really (or almost) 25fps with every fifth frame repeated for 29.970fps. So M-in-5 Decimation isn't quite correct, I don't think. It removes 1 frame in 5 when you want to remove one frame in 6.
MeGUI will probably be adding something like this to the script:
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(cycleR=1)
Ignoring the LoadPlugin line, it adds this:
TDecimate(cycleR=1)
The default cycle is 5 frames. So what MeGUI adds to the script would be the same as this:
TDecimate(cycle=5, cycleR=1)
What you need to do, is change it to this:
TDecimate(cycle=6, cycleR=1)
That'll give you an output of 24.975fps. Which could be correct. The original PAL video could have been slowed down just a tad, every sixth frame repeated, and you end up with 29.970. However in this case I don't think it's exactly every sixth frame repeated. Every so often, and it's far enough apart to make it hard to tell, I think there's a cycle of seven frames before a repeated frame instead of six. I'm too silly to work out the exact decimation required, but fortunately TDecimate has a frame rate mode, so try changing the line MeGUI adds to the script to this:
TDecimate(mode=2, rate=25)
I think that's correct for some, although maybe not all. It tells TDecimate to delete the number of frames required for 25fps. It might pay to try both yo see which looks smoother. For a couple of samples they're too short for it to make any difference which you use. Whichever one you do use though, the audio sync won't be effected because the frame rate changes accordingly (when a different number of duplicate frames are removed).
The sample mentioned earlier that's progressive encoded as interlaced..... it requires the same decimation.
If you want to append the extras to another MKV with a different frame rate you can, although MKVMergeGUI offers a warning, but the muxed/appended video plays okay. Or you can leave it at 29.970fps with the duplicate frames, but motion may look a bit jittery in places (depends how much motion there is), or....
You could decimate the duplicate frames and convert to 29.970fps using frame blending. There may be a more clever way to do it but using Avisynth:
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(mode=2, rate=25)
ConverFPS(30000,1001)
I'd be tempted to try that, especially if there's very little movement. You might see what looks like occasional blurred frames due to the frame blending, but it might also be less noticeable than jittery motion due to repeated frames.
A couple of samples. Same script, with and without the ConvertFPS line. QTGMC in progressive mode to stabilise it a bit.
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\BG2009 2 VTS_01_1 extrait3.demuxed.d2v")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(cycle=6, cycleR=1)
ConvertFPS(30000,1001)
QTGMC(InputType=1)
Spline36Resize(704,396)
I used this one as an example as the frame blending is more obvious where the camera pans near the beginning, but for the rest of it, not so much.Last edited by hello_hello; 12th Oct 2015 at 19:37.
-
A lot of it's personal taste, but it might pay to convert to RGB so you can use RGBAdjust. As you can imagine, the numbers represent red, green and blue, with a value of 1 meaning it's unchanged. I thought the second sample was maybe a little blue.Originally Posted by abolibibelot
That's just a guess. I didn't try it. But you can also adjust the gamma of each colour if need be rather than simply increase or decrease the amount, and you can still follow it with Tweak if need be to change the saturation or contrast etc. http://avisynth.nl/index.php/RGBAdjust
ConvertToRGB()
RGBAdjust(1,1,0.95)
ConvertToYV12()
Tweak(sat=1.1) -
[QUOTE=hello_hello;2413992]So nothing I said about PAL video applies to your samples. It's not wrong. It just doesn't apply here. Sorry.[QUOTE]
No harm done, it was informative nonetheless.
No, it doesn't allow to extract chapters/subtitles directly, it still has to be done separately, but I find it convenient then to add it all in one place.I assume OneClick can extract chapters and subtitles for you, whereas when using AutoEncode you need to extract them yourself first and add them to the AutoEncode job. OneClick was fairly basic when I started using MeGUI and it's gone through a lot of changes, so maybe I should have another look. It may be able to replace AutoEncode with more functionality.
Why foobar2000 ? I recently updated it (I had a 2009 version... I'm very slow at updating in general, not only when it comes to software...) and indeed it does have approximately the same audio encoding abilities as MeGUI (with the right plugins), but still why use two different softwares if one can deal with all the aspects of the task ?I guess for me muxing manually is partly habit, but I rarely re-encode audio with MeGUI these days (if I do I use foobar2000), so I use the script creator to create scripts and load them into the job queue, then manually mux the audio when it's done.
In that case, yes, it's probably the most convenient. Are there sometimes issues with MeGUI when muxing a transcoded video with its native audio ? Anyway MeGUI uses MKVMerge "under the hood" so I guess it's a moot point.But I'm often re-encoding other file types too (ie MKV, MP4, AVI) so I open the encoded video with MKVMergeGUI, add the source file (ie MKV, MP4, AVI), de-select the original video stream and remux. It cuts down on a lot of extracting and ensures the audio sync won't change.
Interesting trick, I'll make note of it, it might come in handy. So when cutting a MKV file with chapters and/or subtitles all the markers are adjusted automatically ? I guess they are, it would be silly if they weren't...And often I remove all the studio and production company promos from the beginning, so rather than split the audio, split subtitles and chapters etc, I create a script to encode just the junk at the beginning, another to encode the rest, append the two encodes with MKVMergeGUI while adding the source file, deselect the original video stream and tell MKVMergeGUI to split the output at the point where the two encodes are appended. The idea being it gives me two new MKVs. One containing just the junk at the beginning I can then delete, and the second one containing the video I want. If there's subtitles and chapters etc they stay in the same position relative to the video so there's no reason to adjust them separately. Oh..... and the reason for encoding the video in two sections.... it ensures there's a keyframe exactly where I want to split.
I had an hesitation when setting the conversion parameters for the "Horacio Hernandez" video, wondering if I should cut the ~7s of silent black and the short company promo at the begining, 11s in total, but decided against it, thinking it would mess up the chapters timings, which I had just painstakingly corrected. This method would have done it nicely, but oh well, it's just 11s. In fact if I open the resulting MKV in Avidemux it says there's an "I" frame exactly at the point where I would cut it, so I guess I can still do it flawlessly. Is there a more convenient/reliable/usual way of identifying the types of frames than Avidemux ?
By the way, I don't know if the chapters were wrongly placed at the time of authoring, or if the "Chapter creator" module is not accurate enough, but they were slightly off for all of those DVDs, and I had to correct them manually, using VirtualDub to get the correct timings. For one of them it was even more complicated as accessing any chapter via the menu (in VLC Player) would only display the duration of the current "part", instead of the whole video (everything being in the same "VTS"), so I had to open the first transcoded MKV in Avidemux to get the proper timings. -
Indeed that what I get.Originally Posted by hello_hello
In this particular case, I'm not so sure anymore that it's worth the trouble... But it's good to know how to deal with such a pattern. I think I'll leave it at 29.97 for the actual encode, but still do the suggested tests, "par acquit de conscience".The default cycle is 5 frames. So what MeGUI adds to the script would be the same as this:
TDecimate(cycle=5, cycleR=1)
What you need to do, is change it to this:
TDecimate(cycle=6, cycleR=1)
That'll give you an output of 24.975fps. Which could be correct. The original PAL video could have been slowed down just a tad, every sixth frame repeated, and you end up with 29.970. However in this case I don't think it's exactly every sixth frame repeated. Every so often, and it's far enough apart to make it hard to tell, I think there's a cycle of seven frames before a repeated frame instead of six. I'm too silly to work out the exact decimation required, but fortunately TDecimate has a frame rate mode, so try changing the line MeGUI adds to the script to this:
TDecimate(mode=2, rate=25)
I think that's correct for some, although maybe not all. It tells TDecimate to delete the number of frames required for 25fps. It might pay to try both yo see which looks smoother. For a couple of samples they're too short for it to make any difference which you use. Whichever one you do use though, the audio sync won't be effected because the frame rate changes accordingly (when a different number of duplicate frames are removed).
Which one do you mean here ?The sample mentioned earlier that's progressive encoded as interlaced..... it requires the same decimation.
As was mentioned above ("_Al_"), those extra features are of rather low quality and/or jerky to begin with (and likely won't be seen more than once by the people watching the damn thing, if that !), so indeed it's probably not worth fiddling with the frame rate.If you want to append the extras to another MKV with a different frame rate you can, although MKVMergeGUI offers a warning, but the muxed/appended video plays okay. Or you can leave it at 29.970fps with the duplicate frames, but motion may look a bit jittery in places (depends how much motion there is), or....
In this case, it's quite obvious indeed. There may be quiet sections but those videos are mostly shot on hand-held cameras and therefore quite jerky, so this method would probably not improve them globally. Besides, doesn't it reduce the quality, since frames are blended, thus interpolated ? (I think there's a small typo in both the short and long version script : as I understand it, it would be "30000,1001".)You could decimate the duplicate frames and convert to 29.970fps using frame blending. There may be a more clever way to do it but using Avisynth:
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(mode=2, rate=25)
ConverFPS(3000,1001)
I'd be tempted to try that, especially if there's very little movement. You might see what looks like occasional blurred frames due to the frame blending, but it might also be less noticeable than jittery motion due to repeated frames.
A couple of samples. Same script, with and without the ConvertFPS line. QTGMC in progressive mode to stabilise it a bit.
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\BG2009 2 VTS_01_1 extrait3.demuxed.d2v")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(cycle=6, cycleR=1)
ConvertFPS(30,0001001)
QTGMC(InputType=1)
Spline36Resize(704,396)
I used this one as an example as the frame blending is more obvious where the camera pans near the beginning, but for the rest of it, not so much. -
But doesn't it cause some significant loss of quality when a double conversion of color space is involved ? Can't this blue shift be corrected directly in YUV (if that's the correct one for native MPEG2), maybe with ColorYUV ? Or is it more convenient / accurate in RGB ?Originally Posted by hello_hello
Besides, are there general methods or guidelines to analyze and correct such color issues with a good accuracy, without having to rely on subjective viewing on a screen which is may or (more likely) may not be well calibrated ? I once tried to investigate this but didn't get very far (this thread ; in that case I gave up correcting the abysmal PAL DVD picture and ended up muxing the improved french audio with the Xvid file I had found, made from the NTSC version -- not a high quality conversion but still better than what I could have done with that damn DVD in terms of colors and even sharpness --, cutting an extra company logo at the begining and setting a delay in MKVMerge which luckily was enough to have it synchronized, and my brother was happy with that...). -
Habit again, but mainly because it'll batch encode and encode multiple files simultaneously. I find it convenient to open a bunch of files at once, highlight them all and click convert. MeGUI will only re-encode audio one at a time. There's also a plugin for foobar2000 that allows it to open and re-encode Avisynth scripts. https://www.foobar2000.org/components/view/foo_input_avsOriginally Posted by abolibibelot
Plus (although I don't downmix a lot these days) if I downmix to stereo I downmix while applying the same gain reduction each time (6dB seems about right to prevent clipping most of the time) whereas MeGUI forces you to normalise or the volume is way too low. I use the downmix/gain reduction method because that way the encoded audio is the same relative to the source each time, which I prefer if I'm downmixing the audio from episodes of the same TV show (for movies I don't mind peak normalising). When it's done, I use foobar2000 to run a ReplayGain scan to check the peak levels to make sure there wasn't any clipping. More messing around, but the end result is the one I prefer.
Not that I'm aware of, but the file indexer can only extract audio from MKVs (or DVDs/mpeg video if you're indexing with DGIndex). For MP4s or AVIs it creates a script to re-encode the audio instead. I'm not sure if OneClick is any different but mostly I prefer to keep the original audio, and remuxing the output video with the source file while deselecting the original video stream seems to be the most efficient way to do it.Originally Posted by abolibibelot
Yes it adjusts them. Same when appending, so it's handy for that too. If you have a video with subtitles in two sections you could extract the subtitles from each and use a subtitle program to append them while banging your head against the desk trying to get it right, or you can append the video with MKVMergeGUI and extract the subtitles as a single file. Job done. Same with audio, although I'd extract it as a single file using the HD Streams Extractor to fix any gaps when extracting. Normal extraction won't fill the gaps with silence.Originally Posted by abolibibelot
x264 is pretty good at putting keyframes on the first frame of a scene, but when there's no change or a slow fade-in etc it's more hit and miss. If you were using the default keyframe settings the max keyframe interval would be 10 seconds, so you probably got lucky.Originally Posted by abolibibelot
Try VirtualDubMod with the ffmeg input driver. The keyframe navigation buttons should work fine, but then again, that'd probably be the same as using AviDemux to find them.
If you open a video with MPC-HC and use the left/right arrows while holding down the Shift key, it'll jump between keyframes. I use it to determine if there's keyframe where I want to cut quite a bit. Ctrl+left/right navigates backwards/forwards one frame at a time, so you can jump to a keyframe then back a single frame to make sure the keyframe was on the first frame of a scene if need be. Only for some reason the first time you use either CTRL+left or CTRL+right it doesn't move backwards/forwards. You need to use the left/right arrow a second time and then it'll start stepping through the frames one at a time. I'm not sure why, but it's something to be aware of.
Might be the way they were ripped. In fact, it'd probably have to be. Why, I'm not sure. Did you edit the video while ripping at all, or re-author it?Originally Posted by abolibibelot
Last edited by hello_hello; 12th Oct 2015 at 19:23.
-
I can't remember. I thought it was the one Al mentioned in post #7, but there's quite a few samples so maybe I got them mixed up. Just ignore that.Originally Posted by abolibibelot
In which case I'd decimate the duplicate frames and convert them back to 29.970 with frame blending.Originally Posted by abolibibelot
For the sample I encoded, while watching them on a TV refreshing at 60Hz, I think the 25fps version looks the smoothest, and while you can see the frame blending in the first part I still prefer the frame blended encode to the original, especially as for the rest of it the frame blending is hard to see. The original at 29.970fps with one frame in 6 duplicated looks the worst to me. It's quite "jittery", even where there's not a lot of motion or camera movement.Originally Posted by abolibibelot
Avisynth doesn't use interpolation to create the extra frames, just blending, so it's not "inventing frames" as such.
http://avisynth.org.ru/docs/english/corefilters/fps.htm
ConvertFPS:
The filter has two operating modes. If the optional argument zone is not present, it will blend adjacent video frames, weighted by a blend factor proportional to the frames relative timing ("Blend Mode").
Yes there was a typo in the script in my previous post. I've fixed it.Last edited by hello_hello; 13th Oct 2015 at 06:03.
-
Some loss, in theory, but I wouldn't call conversion from YV12 to RGB and back a significant loss. Try converting to RGB and back without using RGBAdjust in the middle to see if you can tell the difference between that and the original.Originally Posted by abolibibelot
But doesn't it cause some significant loss of quality when a double conversion of color space is involved ?Originally Posted by hello_hello
No, it can't be done the same way, and yes, RGBAdjust is easier anyway because it's what we're familiar with (at least it is for me).Originally Posted by abolibibelot
Tweak does colour adjustment but I find it pretty hard to get it right and it's still not the same thing.
I use RGBAdjust quite a bit. All the theoretical quality loss in the world means nothing if the result looks better. Especially if you're also using other filtering. I tend to RGBAdjust first, then apply YV12 filtering second (especially if that's something like QTGMC in progressive mode). I used RGBAdjust when re-encoding the video here (the first before and after screenshot, not the second).
https://forum.videohelp.com/threads/370942-MKV-to-Mp4-Conversion?p=2382246&viewfull=1#post2382246
There's plugins for auto-correcting colours and luminance etc, but I haven't played with them much. I've never met one that I thought did it well. Someone may be able to recommend one, but I tend to do that sort of thing "subjectively". And the next day I often come back to it with fresh eyes and wonder what I was subjectively thinking, so I do it all a second time.... subjectively.Originally Posted by abolibibelot
Last edited by hello_hello; 13th Oct 2015 at 06:24.
-
I tried the same sample again, this time using InterFrame for interpolation rather than frame blending to change the frame rate. For this sample at least, I think that's the best 29.97fps outcome. It looks far less jittery than the original with duplicate frames and it's less noticeable than simple frame blending.
Admittedly it does an average job when it comes to the cars going by from right to left at the end, as they're quite blurry to begin with, but that's not exactly typical for your videos.
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\BG2009 2 VTS_01_1 extrait3.demuxed.d2v")
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\TIVTC.dll")
TDecimate(cycle=6, cycleR=1)
QTGMC(InputType=1)
Interframe(NewNum=30000, NewDen=1001, cores=1)
Spline36Resize(704,396)Last edited by hello_hello; 13th Oct 2015 at 06:31.
-
Well, that's interesting, since the two "GH 2006" DVDs have a quite low audio level and I was wondering how I was going to amplifiy them at a "right" level (similar to the others, and of course with no risk of clipping). In MeGUI, in each audio encoder's configuration dialog, there's a "Normalize peaks to ... %" option, so if I understand it correctly it does not force to normalize to 100% (or does no longer if that was the case before -- or maybe what you say here applies only when using the downmix function ?). I haven't tried it yet, though, and it seems to lack a peak scan function of sorts.Originally Posted by hello_hello
I just scanned all audio streams from those two discs with foobar (after installing the AC3 plugin, not included by default), using "ReplayGain > Scan selection as a single album", it gives a global gain value of +9.14dB for D1 (quite a lot indeed ! it goes up to 12 for some parts) and +6.68 for D2. So I guess I'll be safe applying +9 and +6. But how does it translate to a "%" value, if I want to try to do it all within MeGUI first ? And if I can use QAAC in MeGUI, should I also be able to use it in foobar or does it require an extra component ? I just tried (QAAC being installed as part of the "encoder pack") and it fails with the message : "The encoder has terminated prematurely with code 2 (0x00000002)".
I couldn't make it work with VDMod (there's a "plugin" folder instead of "plugin32", I tried to put those files into both "plugin" and "plugin32" to no avail) but it does work very well with the "official" VirtualDub. Does it have the same functionalities as the other individual import plugins for VD (MPEG2, MKV, FLV...), or are these still useful ? And how does it compare with the DirectShow plugin ?Try VirtualDubMod with the ffmeg input driver. The keyframe navigation buttons should work fine, but then again, that'd probably be the same as using AviDemux to find them.
If you open a video with MPC-HC and use the left/right arrows while holding down the Shift key, it'll jump between keyframes. I use it to determine if there's keyframe where I want to cut quite a bit. Ctrl+left/right navigates backwards/forwards one frame at a time, so you can jump to a keyframe then back a single frame to make sure the keyframe was on the first frame of a scene if need be. Only for some reason the first time you use either CTRL+left or CTRL+right it doesn't move backwards/forwards. You need to use the left/right arrow a second time and then it'll start stepping through the frames one at a time. I'm not sure why, but it's something to be aware of.
I see that VirtualDubMod hasn't been updated since 2007 (astonishingly, for once I do have the most recent version !). Is it still relevant compared with the official VirtualDub and its many plugins ?
Regarding MPC-HC, I've had it installed for years as part of a thing called "Satsuki Decoder Pack", which seems quite dubious now that I look at it more closely (I recently checked its home page and was appalled at the amount of typos, which is never a good sign). I then attempted to install CCCP but it said several components on my systems were known to cause problems (I took note of which ones : Gabest MKV Splitter, Gabest MP4 Splitter, DirectVobSub, OggDS Multiplexer, OggDS Splitter, OggDS Vorbis Decoder & Encoder), and I wasn't sure if I should trust this warning and get rid of them (I'm a partisan of the "if it's not broken don't fix it" attitude). So what is currently the most simple and reliable way of having it work with the majority of video/audio formats ? (That's a big advantage of VLC Media Player in that regard, it works right away with pretty much everything, with no need to fiddle with codecs and the like. It's not perfect, though, and for instance it always displays the wrong duration for MPEG2 videos.)
No, not at all, I just extracted them as is, using Robocopy, or DVDFab HD Decrypter for the few encrypted ones. Those shifts were progressively increasing from start to finish. For instance here's the native extracted chapter file for JM 2007, disc 2, part 1 :Originally Posted by abolibibelot
And the modified file with corrected timings (and added chapter names) :Code:CHAPTER01=00:00:00.000 CHAPTER01NAME=Chapter 01 CHAPTER02=00:01:01.067 CHAPTER02NAME=Chapter 02 CHAPTER03=00:05:03.067 CHAPTER03NAME=Chapter 03 CHAPTER04=00:07:19.601 CHAPTER04NAME=Chapter 04 CHAPTER05=00:10:41.435 CHAPTER05NAME=Chapter 05 CHAPTER06=00:17:27.269 CHAPTER06NAME=Chapter 06 CHAPTER07=00:21:08.170 CHAPTER07NAME=Chapter 07 CHAPTER08=00:24:31.237 CHAPTER08NAME=Chapter 08
So by the end there's a ~2sec. discrepancy (of course it's even worse for a 2 hours video). I've had the same results with ChapterGrabber and Chapter Xtractor. I rewatched those files : there's at least one for which I didn't have to correct the timings (BG 2015), and apart from being the longest of all those videos (at 3h05min), it's one for which I had to extract the VOB file with PGCDemux, otherwise the index files generated by DGIndex would be completely messed up, and hence the resulting test encodes. But there's another for which I had to do the same (JM 2014, disc 2), and for which I still had to correct the chapter timings, so that shouldn't be the explanation.Code:CHAPTER01=00:00:00.000 CHAPTER01NAME=Introduction CHAPTER02=00:01:01.128 CHAPTER02NAME=The push-pull technique CHAPTER03=00:05:03.003 CHAPTER03NAME=The Mayer stroke / Valving technique CHAPTER04=00:07:20.140 CHAPTER04NAME=The push-pull / french grip CHAPTER05=00:10:42.125 CHAPTER05NAME=Two for one / traditional grip CHAPTER06=00:17:28.414 CHAPTER06NAME=The one-handed roll CHAPTER07=00:21:09.502 CHAPTER07NAME=Interlacing single stroke exercises CHAPTER08=00:24:33.355 CHAPTER08NAME=Performance (solo 3)
If that was the first one (overhead shot of the guy playing the drums, from the actual teaching part which comprises most of that 2-disc set) it is (I'm pretty sure) strictly progressive at native 29.97 FPS (no repeated frames, all fields duplicated when applying a bob deinterlacer), so shouldn't require any special treatment. All the other samples from this disc have indeed the same "1-in-6 repeated" pattern.I can't remember. I thought it was the one Al mentioned in post #7, but there's quite a few samples so maybe I got them mixed up. Just ignore that.
By the way it seems you were right about there being a "1-in-7" pattern in places : for instance with the "extrait4" sample, frames 406-407 are repeated, then 412-413, but then 419-420 (instead of 418-419). And even "1-in-4" : 246-247 are repeated, then 250-251.
You mean, as opposed to converting it separately and restoring the original 25 FPS ?In which case I'd decimate the duplicate frames and convert them back to 29.970 with frame blending.
I was thinking more along the lines of what "_Al_" wrote, that the more motion and jerkiness there is (and there's quite a lot in those sequences), the less noticeable it would make such a "jittery" effect.For the sample I encoded, while watching them on a TV refreshing at 60Hz, I think the 25fps version looks the smoothest, and while you can see the frame blending in the first part I still prefer the frame blended encode to the original, especially as for the rest of it the frame blending is hard to see. The original at 29.970fps with one frame in 6 duplicated looks the worst to me. It's quite "jittery", even where there's not a lot of motion or camera movement.
So what does InterFrame actually do compared with ConvertFPS ?I tried the same sample again, this time using InterFrame for interpolation rather than frame blending to change the frame rate. For this sample at least, I think that's the best 29.97fps outcome. It looks far less jittery than the original with duplicate frames and it's less noticeable than simple frame blending.
Admittedly it does an average job when it comes to the cars going by from right to left at the end, as they're quite blurry to begin with, but that's not exactly typical for your videos.
I haven't yet seen any such quality loss myself (I actually don't know what to look for if it happens) but I keep reading it whenever it appears in a topic.Some loss, in theory, but I wouldn't call conversion from YV12 to RGB and back a significant loss. Try converting to RGB and back without using RGBAdjust in the middle to see if you can tell the difference between that and the original.
Indeed if there's no other way, but I'm wondering if it can be done with the same visual effect while avoiding this (at least theoretically) lossy conversion.No, it can't be done the same way, and yes, RGBAdjust is easier anyway because it's what we're familiar with (at least it is for me).
Tweak does colour adjustment but I find it pretty hard to get it right and it's still not the same thing.
I use RGBAdjust quite a bit. All the theoretical quality loss in the world means nothing if the result looks better. Especially if you're also using other filtering. I tend to RGBAdjust first, then apply YV12 filtering second (especially if that's something like QTGMC in progressive mode). I used RGBAdjust when re-encoding the video here (the first before and after screenshot, not the second).
https://forum.videohelp.com/threads/370942-MKV-to-Mp4-Conversion?p=2382246&viewfull=1#post2382246
Why do you mention specifically QTGMC here ? By the way, if using it as a deinterlacer, it should be applied first, right ? In what cases do you apply it in progressive mode, and what does it improve ? Earlier you mentioned a "stabilizing" effect, but in what sense ?
In this case, I don't even have to sleep in-between or quit looking at the screen : I tweak some parameters until I get a result that looks satisfying, then go back to the native colors and it suddenly seems way overdone...There's plugins for auto-correcting colours and luminance etc, but I haven't played with them much. I've never met one that I thought did it well. Someone may be able to recommend one, but I tend to do that sort of thing "subjectively". And the next day I often come back to it with fresh eyes and wonder what I was subjectively thinking, so I do it all a second time.... subjectively.
I tried to correct the colors for GH2002 with ColorYUV, and for GH2006 with ColorYUV and RGBAdjust + Levels (to increase the gamma) + Tweak (to increase the contrast), probably not doing it right :
http://share.pho.to/9mwY5
After ColorYUV filtering, GH2002 may be a tad too yellow and GH2006 a tad too red/purple, I'll try to tweak some more, but to my eyes it's already an neat improvement ; I couldn't get a similar result with the second method, but using three filters I never tried before is kinda tricky. The "cont" parameter in "Tweak" seems to have an effect more related to the gamma parameter in other tools. And the RGBAdjust parameters are strangely very sensitive to the slightest adjustment, despite the scale going from -255 to +255.Last edited by abolibibelot; 14th Oct 2015 at 11:20.
-
Using ReplayGain still confuses me at times.Originally Posted by abolibibelot
The problem with peak normalisation is different audio tracks have a different dynamic range. So if you normalise the peaks to xx% (as MeGUI's normalisation does) a track with a greater dynamic range (louder peaks) will have a lower average volume than one with less dynamic range. ReplayGain is supposed to work out how loud a track sounds and adjust it accordingly, so the peaks will be different, not the average volume.
The default target volume (it's a long explanation as to how it's defined so just go with it for the moment) is 89dB. So when you scan a file and the result is +9.41dB it means the volume needs to be increased by 9.41dB to reach the target of 89dB. It has nothing to do with the peak levels. If you applied a 9.41dB increase the peaks might still be well under maximum, or they might be clipped, it depends how dynamic the audio is.
When you scan with foobar2000 you'll see a gain value and a peak value. The peak value is a number such as "0.867542". It's a percentage relative to maximum. The upshot of it is when the peaks are exactly at maximum the value will be 1.000000. Anything higher than 1 and the peaks are above maximum (they can be for lossy audio) and anything less than 1 they're lower than maximum.
And for the final brain-melt..... The 89dB target volume is designed for typical CD tracks. It's too high for "soundtrack" audio which is more dynamic. For that, you need to use about 82dB as the target volume to ensure there won't be much likelihood of clipping. Foobar2000 (and all audio programs) use 89dB as the target volume for ReplayGain scanning. If they didn't they'd give different results and the system wouldn't work (it was originally designed to save the volume info in tags so the player could read it and adjust the volume on playback). So if you were to use foobar2000 for soundtrack audio you'd probably scan it, save the ReplayGain info to the files, convert while applying ReplayGain, but while also applying a gain reduction of 7dB to give you a final 82dB target volume.
So those files you scanned. They were scanned with an assumption of an 89dB target volume. For "soundtrack" audio though, you want it about 7dB lower, so that +9.41dB increase would then only be a 2.41dB increase, which means the files you scanned are pretty close to being the volume they should be. Most "professional" audio is, which is why if I'm converting a bunch of episodes of a TV series and I'm converting stereo to stereo or 5.1ch to 5.1ch, I don't peak normalise. When downmixing I usually apply the same gain reduction each time and scan for clipping.
ReplayGain has two scan modes. TrackGain scans tracks individually and adjusts them individually to the same target volume. AlbumGain scans them as a group and adjusts them all by the same amount. It also has options to apply ReplayGain without clipping (if the adjustment would result in clipping the volume will be reduced to prevent it).
Well that kind of turned into a ReplayGain essay. If you want to play around, maybe try MP3Gain to start. It's a bit more user friendly than foobar2000 in respect to the info it shows and you can change the target volume easily. It's designed for changing the volume of MP3s without re-encoding them, but playing with it might be a way to help get your head around ReplayGain. I don't know why all conversion programs don't have the ability to apply ReplayGain these days instead of peak normalisation. The only one I know if which can is Hybrid.
You could also play with R128Gain.
Given we're not already confused enough, it does EBU128 scanning and the volume is expressed in LUFS, not dB. EBU128's reference loudness of -23LUFS is, I'm pretty sure, the same as a target volume of 82dB in ReplayGain terminology.
It has two ReplayGain modes with a reference loudness of -18LUFS, which is the same as ReplayGain's target volume of 89dB. ReplayGain uses the original ReplayGain algorithm (as does MP3Gain), while ReplayGain2 uses the newer EBU algorithm (as does foobar2000), which is probably a little more accurate. In other words, you'd use EBU128 scanning for "soundtrack" audio, and ReplayGain scanning for CD tracks.
You need to download ffmpeg and put it's files in the r128gain-tools folder for decoding many file types.
http://ffmpeg.zeranoe.com/builds/win32/shared/
I've only ever used ReplayGain on stereo audio. The new standard supports multi-channel but I haven't tested foobar2000's scanning with multi-channel audio.
Yes you can use QAAC with foobar2000. You need to have the required quicktime files in the encoders folder or have quicktime installed (have you extracted the files from the quicktime installer with makeportable?), the same as you do before MeGUI can use QAAC. Or, if QAAC is working for MeGUI, tell foobar2000 to use QAAC in the MeGUI tools folder instead. And foobar2000 can normalise when encoding with QAAC, because QAAC can normalise on it's own (-N in the command line).
Here's foobar2000 using MeGUI's copy of QAAC and normalising (custom encoder configuration):
If you select the Apple AAC encoder from the dropdown list and set the desired mode and bitrate/quality etc, then select "custom" that'll get you started with the correct command line and you can modify things from there.
It won't work with VirtualDubMod.I couldn't make it work with VDMod (there's a "plugin" folder instead of "plugin32", I tried to put those files into both "plugin" and "plugin32" to no avail) but it does work very well with the "official" VirtualDub. Does it have the same functionalities as the other individual import plugins for VD (MPEG2, MKV, FLV...), or are these still useful ? And how does it compare with the DirectShow plugin ?
I see that VirtualDubMod hasn't been updated since 2007 (astonishingly, for once I do have the most recent version !). Is it still relevant compared with the official VirtualDub and its many plugins ?
When opening a file with VirtualDub, selecting "ffmpeg supported files" in the file type list will ensure it uses the ffmpeg input driver to open them. The ffmpeg input driver always decodes, so it's like using DirectShow in that respect, only it's far more reliable. Because it decodes, you can't use Direct Stream Copy when saving files. Some plugins probably allow VirtualDub to open files but still require a "system" codec to decode. I think the MKV plugin is one of those. You could use Direct Stream Copy in that case.
MPC-HC is just like VLC these days, in that it's self contained. No system codecs or splitters required. Just download the portable version, unzip it and run it. Maybe go into it's options and reset it (under the misc tab, I think) if you've had an older version installed.Regarding MPC-HC, I've had it installed for years as part of a thing called "Satsuki Decoder Pack", which seems quite dubious now that I look at it more closely (I recently checked its home page and was appalled at the amount of typos, which is never a good sign). I then attempted to install CCCP but it said several components on my systems were known to cause problems (I took note of which ones : Gabest MKV Splitter, Gabest MP4 Splitter, DirectVobSub, OggDS Multiplexer, OggDS Splitter, OggDS Vorbis Decoder & Encoder), and I wasn't sure if I should trust this warning and get rid of them (I'm a partisan of the "if it's not broken don't fix it" attitude). So what is currently the most simple and reliable way of having it work with the majority of video/audio formats ? (That's a big advantage of VLC Media Player in that regard, it works right away with pretty much everything, with no need to fiddle with codecs and the like. It's not perfect, though, and for instance it always displays the wrong duration for MPEG2 videos.)
If nothing requires them, you could probably let CCCP uninstall the above stuff without issue. MeGUI requires the Haali Media Splitter for some file types. Other than that and ffdshow, I don't have any other third party codecs/splitters installed myself.
I'd probably just be guessing widely without a sample to play with.Originally Posted by abolibibelot
To be honest I'm not sure if that's because the original frame rate was 25fps (rather than 24.975) or just the result of editing (probably editing), but for one sample I thought 6-1 decimation took out a frame it shouldn't and for another I thought the 25fps decimation left one in. That's why I suggested trying both, if one resulted in the odd "jerky" movement. Or try it with a frame rate of 24.975 instead of 25. None might be perfect, but they should be very close.By the way it seems you were right about there being a "1-in-7" pattern in places : for instance with the "extrait4" sample, frames 406-407 are repeated, then 412-413, but then 419-420 (instead of 418-419). And even "1-in-4" : 246-247 are repeated, then 250-251.
ConvertFPS takes the previous and next frame at a particular point in time and blends them together to produce a new frame, whereas Interframe would try to create an "interpolated" frame. It's designed to do the same thing as the interpolation built into TVs, to give you 50fps progressive from 25fps progressive, or 59.970fps from 23.976fps etc in order to make motion smoother, but you can specify a desired output frame rate.So what does InterFrame actually do compared with ConvertFPS ?
The way I understand it, it's only lossy because of the chroma sub-sampling. For YV12 or 4:2:0 there's only one chroma value between a group of four pixels, so when you convert to RGB, that chroma value is "shared" between 4 pixels (exactly as it happens when converting to RGB on playback), because for RGB each pixel has it's own colour. RGB is lossless. I don't fully understand the subsampling process, but I assume when going from RGB back to YV12 there's no guarantee the subsampling will will be identical and if you keep converting back and forth, I guess eventually that's going to translate into a difference that'd be seen as a loss in quality. The thing is though, the purpose of converting to RGB here is to fiddle with the colour anyway. VirtualDub's filters are largely "RGB only" so it's been converting from YV12 to RGB forever. I think by default, it's "normal" and "full" compression modes both output RGB even when you're not using filtering.I haven't yet seen any such quality loss myself (I actually don't know what to look for if it happens) but I keep reading it whenever it appears in a topic.
The reason I mentioned QTGMC is because it works with YV12 video and if I was using it to clean the video up I'd put it after the conversion, but chances are I'd follow the conversion with some sort of filtering that fiddles with YV12 anyway.
So you're converting to RGB, fiddling with the colours, subsampling back to YV12, and in my case probably using QTGMC to process that YV12 video, then re-compressing it with a lossy compressor, so in the over-all scheme of things, how much difference is one subsampling step going to make, especially if you can use visually improve the colours as a result?
I thought I used it on that screenshot for noise removal after the conversion to RGB, but (I've learned to hoard scripts so I can recall what I did later on) it would appear QTGMC wasn't required for that one and I used SMDegrain instead.Why do you mention specifically QTGMC here ?
ConvertToRGB()
RGBAdjust(1, 0.97, 1)
ConvertToYV12()
Tweak(sat=1.04)
SMDegrain()
LSFMod(strength=50)
Gradfun3()
I've learned to open the original video in MPC-HC, open a script containing the colour adjusting etc in another instance of MPC-HC and use the original as a reference while I fiddle (if you change a script you can simply reload it in MPC-HC with Ctrl+E). That helps cut down on the "getting stupidly carried away" factor quite a bit, but even so, I still sometimes come back the next day for a fresh look and think " I should have done this".....In this case, I don't even have to sleep in-between or quit looking at the screen : I tweak some parameters until I get a result that looks satisfying, then go back to the native colors and it suddenly seems way overdone, the skin tones appear almost red-ish...
I actually prefer the second screenshot out of all of them.I tried to corret the colors for GH2002 with ColorYUV, and for GH2006 with ColorYUV and RGBAdjust + Levels (to increase the gamma) + Tweak (to increase the contrast), probably not doing it right :
http://share.pho.to/9mwY5
After ColorYUV filtering, GH2002 may be a tad too yellow and GH2006 a tad too red/purple, I'll try to tweak some more, but to my eyes it's already an neat improvement ; I couldn't get a similar result with the second method, but using three filters I never t
As an example though, take an image and use RGBAdjust to remove 50% of the blue.
ConvertToRGB()
RGBadjust(1,1,0.5)
It's not meant to be pretty (just an example) but how do you replicate that using ColourYUV? If you can, I've never been able to get my head around it. I understand RGB but U and V.... I can't translate it to real world colour in my head. Is it possible?
You can do something similar with Tweak. Actually, it's closer to being totally different than similar, and I've never quite got my head around using it effectively either (although it's been useful on the odd occasion), but it might be worth a play. As an example, I made his jeans grey.
Tweak(startHue=280, endHue=330, sat=0)
Last edited by hello_hello; 14th Oct 2015 at 09:27.
-
OK, so here for disc 1 it says "album gain" +9.62 (I don't know why it's different from last night -- oh, yes, I had omitted two "alternative" tracks) and "album peak" 0.6978 (while individual track gain can be as high as 20.01 and individual peak as low as 0.08) ; disc 2 : album gain 6.68, album peak 0.7306. In this case, with 14 tracks (those 3 DVDs also have the particularity of being divided in individual "VTS" as opposed to continuous videos with chapters like the others) and track peak ranging from 0.08 (only talking) to 0.698 (rock music performance) I guess the result of using "normalize to XX%" would be rather unpredictable. So in such a situation you would apply foobar's "album gain", and then check again the output to verify if there are no peaks above maximum ?Using ReplayGain still confuses me at times.
The problem with peak normalisation is different audio tracks have a different dynamic range. So if you normalise the peaks to xx% (as MeGUI's normalisation does) a track with a greater dynamic range (louder peaks) will have a lower average volume than one with less dynamic range. ReplayGain is supposed to work out how loud a track sounds and adjust it accordingly, so the peaks will be different, not the average volume.
The default target volume (it's a long explanation as to how it's defined so just go with it for the moment) is 89dB. So when you scan a file and the result is +9.41dB it means the volume needs to be increased by 9.41dB to reach the target of 89dB. It has nothing to do with the peak levels. If you applied a 9.41dB increase the peaks might still be well under maximum, or they might be clipped, it depends how dynamic the audio is.
When you scan with foobar2000 you'll see a gain value and a peak value. The peak value is a number such as "0.867542". It's a percentage relative to maximum. The upshot of it is when the peaks are exactly at maximum the value will be 1.000000. Anything higher than 1 and the peaks are above maximum (they can be for lossy audio) and anything less than 1 they're lower than maximum.
I scanned GH 2002 too : 26 tracks, "album gain" +0.53 (so no need to amplify there) but "album peak" 1.011765, with all tracks being within normal range except the last one (a music performance with the drums high in the mix -- indeed if I open it in Audacity it shows four vertical red lines, i.e. four instances of clipping).
So it has to modify the files (to save ReplayGain info) before converting them ? (In which case I'd prefer to copy them first, just in case.)And for the final brain-melt..... The 89dB target volume is designed for typical CD tracks. It's too high for "soundtrack" audio which is more dynamic. For that, you need to use about 82dB as the target volume to ensure there won't be much likelihood of clipping. Foobar2000 (and all audio programs) use 89dB as the target volume for ReplayGain scanning. If they didn't they'd give different results and the system wouldn't work (it was originally designed to save the volume info in tags so the player could read it and adjust the volume on playback). So if you were to use foobar2000 for soundtrack audio you'd probably scan it, save the ReplayGain info to the files, convert while applying ReplayGain, but while also applying a gain reduction of 7dB to give you a final 82dB target volume.
Yet those two discs (GH2006 -- actually two sides of a double-sided DVD) sound definitely lower than the others (including GH2002). And since the maximum peak is only at 0.7 I'd say there's quite some room for improvement. Or what would be the potential downside of having it peak at 1.00, or 0.95 ?So those files you scanned. They were scanned with an assumption of an 89dB target volume. For "soundtrack" audio though, you want it about 7dB lower, so that +9.41dB increase would then only be a 2.41dB increase, which means the files you scanned are pretty close to being the volume they should be. Most "professional" audio is, which is why if I'm converting a bunch of episodes of a TV series and I'm converting stereo to stereo or 5.1ch to 5.1ch, I don't peak normalise. When downmixing I usually apply the same gain reduction each time and scan for clipping.
Yes, I saw that when attempting to convert those tracks, it has : "apply gain", "apply gain and prevent clipping according to peak", and "prevent clipping according to peak". But it has to find previously recorded ReplayGain info on the track itself, it can't directly apply the value obtained from the scan ?ReplayGain has two scan modes. TrackGain scans tracks individually and adjusts them individually to the same target volume. AlbumGain scans them as a group and adjusts them all by the same amount. It also has options to apply ReplayGain without clipping (if the adjustment would result in clipping the volume will be reduced to prevent it).
I must have a dozen ffmpeg instances inside my program installations... It's becoming kinda ubiquitous these days. (All the programs using it should have the option to use it from a selected location, so as to reduce the redundancy.)You could also play with R128Gain.
Given we're not already confused enough, it does EBU128 scanning and the volume is expressed in LUFS, not dB. EBU128's reference loudness of -23LUFS is, I'm pretty sure, the same as a target volume of 82dB in ReplayGain terminology.
It has two ReplayGain modes with a reference loudness of -18LUFS, which is the same as ReplayGain's target volume of 89dB. ReplayGain uses the original ReplayGain algorithm (as does MP3Gain), while ReplayGain2 uses the newer EBU algorithm (as does foobar2000), which is probably a little more accurate. In other words, you'd use EBU128 scanning for "soundtrack" audio, and ReplayGain scanning for CD tracks.
You need to download ffmpeg and put it's files in the r128gain-tools folder for decoding many file types.
http://ffmpeg.zeranoe.com/builds/win32/shared/
I searched how I managed to make it work in MeGUI : I downloaded the CoreAudioToolbox DLLs from this russian page, and copied them into the "qaac" folder inside MeGUI, so it's normal it doesn't work in foobar. I copied those same files inside foobar's "encoders" folder and now it works, but the other method you proposed works just as well (exact same output, except the tag info showing a different timestamp and QAAC version).Yes you can use QAAC with foobar2000. You need to have the required quicktime files in the encoders folder or have quicktime installed (have you extracted the files from the quicktime installer with makeportable?), the same as you do before MeGUI can use QAAC. Or, if QAAC is working for MeGUI, tell foobar2000 to use QAAC in the MeGUI tools folder instead. And foobar2000 can normalise when encoding with QAAC, because QAAC can normalise on it's own (-N in the command line).
Here's foobar2000 using MeGUI's copy of QAAC and normalising (custom encoder configuration):
[Attachment 34038 - Click to enlarge]
If you select the Apple AAC encoder from the dropdown list and set the desired mode and bitrate/quality etc, then select "custom" that'll get you started with the correct command line and you can modify things from there.
Regarding normalization : but in that case it would be a bad idea to simply normalize each track, right ?
Fine then, I'll eagerly go from something more streamlined...MPC-HC is just like VLC these days, in that it's self contained. No system codecs or splitters required. Just download the portable version, unzip it and run it. Maybe go into it's options and reset it (under the misc tab, I think) if you've had an older version installed.
If nothing requires them, you could probably let CCCP uninstall the above stuff without issue. MeGUI requires the Haali Media Splitter for some file types. Other than that and ffdshow, I don't have any other third party codecs/splitters installed myself.
Did you try CCCP, and it it any useful if VLC & MPC work with everything on their own ?
I don't see how I could provide a small sample to test the accuracy of chapter extraction... Anyway, I already corrected all of them manually, but it would still be interesting to have an explanation and a possible workaround for the next time I have a DVD to convert.I'd probably just be guessing widely without a sample to play with.
The same issue was mentioned here :
http://forum.doom9.org/archive/index.php/t-143497.html
Could be related to a frame rate issue, they say, the video being considered as 30 FPS instead of 29.97 (yet all the MKVs I created have a proper 29.97 FPS rate).
In this case, how did you determine that SMDegrain was preferable to QTGMC, since you would have used the latter for noise removal/stabilization as well ?I thought I used it on that screenshot for noise removal after the conversion to RGB, but (I've learned to hoard scripts so I can recall what I did later on) it would appear QTGMC wasn't required for that one and I used SMDegrain instead.
ConvertToRGB()
RGBAdjust(1, 0.97, 1)
ConvertToYV12()
Tweak(sat=1.04)
SMDegrain()
LSFMod(strength=50)
Gradfun3()
What was the purpose of LSFMod and Gradfun3 here ?
Just to be clear, those two screenshots are from two different DVDs, the second one having a worse color problem to begin with.I actually prefer the second screenshot out of all of them.
I have no idea, if someone more knowledgeable could chime in...As an example though, take an image and use RGBAdjust to remove 50% of the blue.
ConvertToRGB()
RGBadjust(1,1,0.5)
It's not meant to be pretty (just an example) but how do you replicate that using ColourYUV? If you can, I've never been able to get my head around it. I understand RGB but U and V.... I can't translate it to real world colour in my head. Is it possible?
Strangely, "startHue" & "endHue" don't seem to have any effect (in AvsPmod).You can do something similar with Tweak. Actually, it's closer to being totally different than similar, and I've never quite got my head around using it effectively either (although it's been useful on the odd occasion), but it might be worth a play. As an example, I made his jeans grey.
[Attachment 34039 - Click to enlarge]
Tweak(startHue=280, endHue=330, sat=0)
[Attachment 34040 - Click to enlarge]
One thing I don't understand is that the "cont" parameter does not behave as contrast settings usually do in other video or image processing softwares. Normally it enhances the difference between adjacent colors, making the picture appear more "vivid" ; here it makes the picture globally brighter (quickly burning the whites) and paler, the dark areas become brighter too.
Yet on Level's description page I read "For adjusting brightness or contrast it may be better (depending on the effect you are looking for) to use Tweak or ColorYUV, because Levels changes the chroma of the clip."
And on ColorYUV's page, about "cont" parameter :
"Although it is possible, it doesn't make sense to apply this setting to the luma of the signal." (Yet it seems to work, and thus to "make sense".)
And :
"gain is a multiplier for the value, and it stretches the signal up from the bottom. In order to confuse you, in the filter Tweak this setting is called contrast. That means that if the gain is set to 0, it preserves the values as they are. When gain is 256 all values are multiplied by 2 (twice as bright). If the gain is 512 all values are multiplied by 3. Thus if gain = k*256 for some integer k then Y becomes (k+1)*Y (idem for the chroma). Although it is possible, it doesn't make sense to apply this setting to the chroma of the signal. "
So what is the usual/prefered way of correcting the contrast with Avisynth ?
EDIT : Apparently there is no clearly defined way of adjusting the contrast :
http://forum.doom9.org/showthread.php?t=153022
https://forum.videohelp.com/threads/345541-Avisynth-equivalent-of-VDub-brightness-contrast-gamma
And I kinda feel like "Mephesto" in that thread :
"How gay. Why did Vdub and Tweak take the weird route? I really hate experimenting with combos of more or less brightness, contrast and gamma just to fix a fudged up DVD (even Blu-ray) that release their shit highly under-saturated."Last edited by abolibibelot; 14th Oct 2015 at 23:04.
-
Now, another weird issue : the Avisynth scripts loaded in AvsPmod and VirtualDubMod don't look the same.
http://share.pho.to/9n4Vj
Here the first picture shows my last attempt at correcting that damn video with ColorYUV, it looked quite satisfying in AvsPmod, then I loaded the script in VirtualDubMod (2nd picture) and suddently it had way too much contrast. Then I loaded a former version in VirtualDub (4th picture) and it looked nice (better than pic 1), yet it was nowhere near as good looking in AvsPmod (3rd pic). What can explain such a difference, and which one should I trust as reliably showing the effect of the applied filters ? (I've finished converting all the other DVDs, those 3 are the ones remaining and they're giving me headaches.) -
I'm started with this post as I don't have lots of time at the moment. I'll reply to your previous post later.Originally Posted by abolibibelot
It looks like a luminance levels issue.
Video normally uses limited range levels (16-235) where 16 is black and 235 is white.
PCs (and RGB) use full range levels (0-255) where 0 is black and 255 is white.
So for video to display correctly using a PC, the limited range levels need to be expanded to full range. The player and/or video card normally takes care of that. When converting YV12 to RGB they'd usually also be expanded, and when converting RGB to YV12 they'd be reduced. And in a perfect world the levels would always look correct, but.....
If you display limited range level video on a PC without expanding it, 16, which is supposed to be black, is now dark grey and the video looks washed out. If you display full range video and expand it, everything from 0-16 effectively becomes black and the video looks too dark, or appears to have too much contrast. That's what seems to be happening, but off the top of my head if it's just a VirtualDubMod problem, I'm not sure why. The levels are being expanded twice by the time you see the preview, maybe once by VirtualDubMod and again by the video card. Try the same script with VirtualDub or MPC-HC or simply ignore how the VidrtualDubMod preview looks and encode it. I'm pretty sure the VirtualDubMod image is wrong and it'll encode normally.Last edited by hello_hello; 15th Oct 2015 at 01:56.
-
But the same script loaded in MeGUI looks just like in VirtualDubMod. In MPC it's very slow (because of QTGMC) thus impractical, but seems to also look like VDM, and different from AvsPmod.I'm started with this post as I don't have lots of time at the moment. I'll reply to your previous post later.
It looks like a luminance levels issue.
Video normally uses limited range levels (16-235) where 16 is black and 235 is white.
PCs (and RGB) use full range levels (0-255) where 0 is black and 255 is white.
So for video to display correctly using a PC, the limited range levels need to be expanded to full range. The player and/or video card normally takes care of that. When converting YV12 to RGB they'd usually also be expanded, and when converting RGB to YV12 they'd be reduced. And in a perfect world the levels would always look correct, but.....
If you display limited range level video on a PC without expanding it, 16, which is supposed to be black, is now dark grey and the video looks washed out. If you display full range video and expand it, everything from 0-16 effectively becomes black and the video looks too dark, or appears to have too much contrast. That's what seems to be happening, but off the top of my head if it's just a VirtualDubMod problem, I'm not sure why. The levels are being expanded twice by the time you see the preview, maybe once by VirtualDubMod and again by the video card. Try the same script with VirtualDub or MPC-HC or simply ignore how the VidrtualDubMod preview looks and encode it. I'm pretty sure the VirtualDubMod image is wrong and it'll encode normally.
But it there's an option in AvsPmod to change the mode of conversion YUV > RGB and it was set to "PC levels", apparently the correct setting is "TV levels", is that right ? With "TV levels" it looks like VDM, I think. Well, I'm too tired to sort it out now, I'll make some more tests when I wake up (and let's hope I can get it over with !). Thanks for your time and all your contributions. -
1.011765 is over maximum, but as lossy audio can store peaks above maximum (0dB in Audacity) it's probably not clipped as such. When audacity imports audio, it imports it in a format (32 bit float) that can also have peaks above 0dB, so the audio wouldn't actually be clipped until it's exported to another format. The peaks probably haven't been flattened. Plus when lossy audio is decoded, the output mightn't be exactly the same as the input (encoded audio with peaks of 0dB might decode with peaks just over 0dB).Originally Posted by abolibibelot
If you want to know the formula for converting percentage to dB, it's "20 log10 x", so for your peak it's 20 x log10 1.011765 = 0.102dB, or next to nothing above 0dB. It's not enough that I'd worry about it. Maybe for peaks of 1.100000 I'd consider reducing the volume. But that's still less than 1dB above 0dB.
The ReplayGain info is saved in tags. The audio itself isn't modified when you save the ReplayGain info, and it has an option to remove it. Making a copy first can't hurt though.So it has to modify the files (to save ReplayGain info) before converting them ? (In which case I'd prefer to copy them first, just in case.)
Foobar2000 can also modify MP3 and AAC volume without re-encoding it (so it's lossless). Unlike MP3Gain though, it doesn't save "undo info". MP3Gain saves the original volume in the same tags so it can reverse the process if you want it to, as long as the tags remain.
Would you believe 0.7 is only -3dB? The conversion between % and dB isn't intuitive (given dB is logarithmic). 20 x log10 0.7 = -3.09dBYet those two discs (GH2006 -- actually two sides of a double-sided DVD) sound definitely lower than the others (including GH2002). And since the maximum peak is only at 0.7 I'd say there's quite some room for improvement. Or what would be the potential downside of having it peak at 1.00, or 0.95 ?
There's no real downside to having peaks at 1.00 or 0.95. Well..... because there's a potential for the peaks to be slightly different than the original when decoding lossy audio, it's often recommended to keep the peaks at a maximum of -3dB to allow for a little headroom. I can't say I've ever bothered myself. Most playback systems should have some headroom over 0dB without clipping the audio.
I don't think there's a way to scan and convert in one step. You need to scan, save the ReplayGain info to the files, then tell the converter to apply it will converting.Yes, I saw that when attempting to convert those tracks, it has : "apply gain", "apply gain and prevent clipping according to peak", and "prevent clipping according to peak". But it has to find previously recorded ReplayGain info on the track itself, it can't directly apply the value obtained from the scan ?
The QAAC version itself doesn't matter too much (unless there's a bug), as it's just a "front end" for using the CoreAudioToolbox for encoding. The latest version seems to be CoreAudioToolbox 7.10.5.0.I searched how I managed to make it work in MeGUI : I downloaded the CoreAudioToolbox DLLs from this russian page, and copied them into the "qaac" folder inside MeGUI, so it's normal it doesn't work in foobar. I copied those same files inside foobar's "encoders" folder and now it works, but the other method you proposed works just as well (exact same output, except the tag info showing a different timestamp and QAAC version).
MeGUI's version of QAAC is updated more regularly than the one in the foobar2000 encoder pack. Just replace it with MeGUI's version, if need be.
I almost never normalise, but I was just pointing out QAAC can. If you want to normalise when re-encoding with foobar2000, I think the only way to do it is to open the audio via an Avisynth script and include normalize(). Avisynth will normalise and foobar2000 can do the re-encoding. That's how MeGUI does it.Regarding normalization : but in that case it would be a bad idea to simply normalize each track, right ?
As a side note, if you copy the script below, save it with an avsi extension (call it whatever you like), and stick it in the installed Avisynth plugins folder, you should be able to downmix and normalise 5.1ch audio simply by adding Downmix() to a script. It normalizes to 0.98, but you can modify it if you like.
I used CCCP years ago, but these days I just install the stuff I want to use myself. I don't think CCCP is harmful though, and if it offers to uninstall obsolete or problem codecs, maybe that's a good thing. Aside from MPC-HC and LAV filters, I don't know what CCCP installs these days.Code:function Downmix(clip a, float "centergain", float "surroundgain", bool "surroundfx") { a.ConvertAudioToFloat() ## channel layouts: http://avisynth.nl/index.php/GetChannel ## (this is WAV 5.1) fl = GetChannel(1) fr = GetChannel(2) fc = GetChannel(3) lf = GetChannel(4) sl = GetChannel(5) sr = GetChannel(6) ## add center gc = Default(centergain, 1.0) * 0.7071 fl = MixAudio(fl, fc, 1.0, gc) fr = MixAudio(fr, fc, 1.0, gc) ## add surround gs = Default(surroundgain, 1.0) * 0.7071 fl = MixAudio(fl, sl, 1.0, gs) fr = MixAudio(fr, sr, 1.0, gs) ## cross-mix surround delayed & out-of-phase ## to emulate back speaker location ?? fx = Default(surroundfx, false) fl = fx ? MixAudio(fl, sr.DelayAudio(0.02), 1.0, -0.7071*gs) : fl fr = fx ? MixAudio(fr, sl.DelayAudio(0.02), 1.0, -0.7071*gs) : fr MergeChannels(fl, fr) Normalize(0.98) #ConvertAudioTo16bit() }
Frame rate is the only explanation I could think of, but I don't know why it'd happen and I didn't want to speculate too much. You could try using MakeMKV to convert the DVD files to MKV, and if it gets the chapters right, extract them from the MKVs it creates. It'd have to be easier than having to adjust them all manually.Could be related to a frame rate issue, they say, the video being considered as 30 FPS instead of 29.97 (yet all the MKVs I created have a proper 29.97 FPS rate).
The best QTGMC vs SMDegrain explanation in respect to when I use them would be via this analogy.In this case, how did you determine that SMDegrain was preferable to QTGMC, since you would have used the latter for noise removal/stabilization as well ?
What was the purpose of LSFMod and Gradfun3 here ?
Image a video with an unstable picture or compression artefacts etc. Maybe it was badly de-interlaced, or encoded with Xvid, or just not very good quality. It can be all those things without being "noisy" as such.
Likewise, a picture can be very stable, progressive with no compression artefacts and yet be noisy when it comes to film grain etc.
So if the picture is unstable and/or noise removal is required, I'd use QTGMC as it stabilises and removes noise. SMDegrain only denoises. Sometimes though, even when the picture is stable I prefer one denoising over the other, so that's the one I use. Whatever works best.
Here's an example of QTGMC's ability to stabilise the picture (in progressive mode) as well as remove noise. It's a torture test sample I used when I first started experimenting with QTGMC for noise removal rather than only use it for de-interlacing. There's sample encodes comparing QTGMC to FastDegrain and TemporalDegrain.
QTGMC(InputType=1, EzDenoise=6) and TemporalDegrain() proved to be fairly similar with that sample, with TemporalDegrain removing a tiny bit more noise, but it was designed for pretty heavy duty noise removal. QTGMC had avantages of it's own. It repaired some of the "single frame" blemishes a little better and reduced the "bobbing" more.
Yes, but that aside, looking at all the screenshots together I think the second one looks the most natural.Just to be clear, those two screenshots are from two different DVDs, the second one having a worse color problem to begin with.
They should, but they set the boundary. You still need to adjust the saturation up or down to see a difference. In my case I set it to zero (no colour).Strangely, "startHue" & "endHue" don't seem to have any effect (in AvsPmod).
I "think" when you use levels, if the picture becomes darker, the colour seems to become more saturated, or something like that. That's probably what's meant by "changes the chroma". I'm not 100% sure how it works to be honest. There's a script called Ylevels which functions the same way as Levels but it "Processes only luma. This makes it faster and allows better preservation of color saturation"One thing I don't understand is that the "cont" parameter does not behave as contrast settings usually do in other video or image processing softwares. Normally it enhances the difference between adjacent colors, making the picture appear more "vivid" ; here it makes the picture globally brighter (quickly burning the whites) and paler, the dark areas become brighter too.
Yet on Level's description page I read "For adjusting brightness or contrast it may be better (depending on the effect you are looking for) to use Tweak or ColorYUV, because Levels changes the chroma of the clip."
I'm not sure about the "preferred way of correcting the contrast ". I'm running out of time again. I'll have to ponder that later.And on ColorYUV's page, about "cont" parameter :
"Although it is possible, it doesn't make sense to apply this setting to the luma of the signal." (Yet it seems to work, and thus to "make sense".)
And :
"gain is a multiplier for the value, and it stretches the signal up from the bottom. In order to confuse you, in the filter Tweak this setting is called contrast. That means that if the gain is set to 0, it preserves the values as they are. When gain is 256 all values are multiplied by 2 (twice as bright). If the gain is 512 all values are multiplied by 3. Thus if gain = k*256 for some integer k then Y becomes (k+1)*Y (idem for the chroma). Although it is possible, it doesn't make sense to apply this setting to the chroma of the signal. "
So what is the usual/prefered way of correcting the contrast with Avisynth ?
I rarely use "cont" myself. I tend to use Levels or Ylevels and expand or reduce the range of levels, and adjust the gamma and saturation if need be. Colour-wise, the result of using Levels and YLevels is definitely different, so I go with the one I prefer at the time.
For example if a video looks a bit washed out, or the black levels aren't very dark, I might do something like this:
YLevels(8,1,245, 0,255)
So it's not a TV to PC levels conversion, but something in between that effectively increases the contrast.
Likewise for less contrast:
YLevels(0,1,255,8,245)
Or to increase the contrast without making black darker.
YLevels(0,1,240,0,255)
That sort of thing. I just do what I find works. Then I come back the next day and do it again.
I'll read the doom9 threads you linked to later and see if I can get my head around the contrast question. Maybe someone else will come along.....Last edited by hello_hello; 15th Oct 2015 at 07:18.
-
If you want to use QTGMC in a script and open it with MPC-HC, try slowing the frame rate down temporarily. ie put something like put this at the end of the script:Originally Posted by abolibibelot
AssumeFPS(2,1)
MPC-HC will try to render at the correct frame rate, and when QTGMC is too slow to keep up it'll stop and stutter etc so slowing the frame rate down to a few frames per second should allow MPC-HC to play through the video smoothly. Very slowly, but smoothly.
I'll play with AvsPmod to see what it's doing in respect to the levels a bit later too. -
Yes. It confused me at first, but I think via that setting you're telling AvsPmod what levels the source video uses. When it's set to TV levels it expects the input video to be TV levels so it expands to PC levels. When it's set to PC levels it expects the source to be PC levels so it does nothing. It appears when it's set to PC levels it also tells the video card the source is PC levels so the video card doesn't expand them either, assuming it's set to do so. That seems to be how it works but it also seems counter-intuitive to me. The correct setting should be TV levels though.... I'm pretty sure.Originally Posted by abolibibelot
Most video cards have a setting for video levels. For Nvidia it looks like this:
If you set you video card to always output full range levels, video should always display correctly (it's set to limited/TV levels in the screenshot because I was playing around). If a player is already expanding the levels they shouldn't be expanded twice (I assume the player tells the video card it's full range). VLC is an exception for me. The video card settings have no effect. For me VirtualDubMod was already expanding the levels. MPC-HC wasn't (the renderer I use doesn't expand the levels, but when I set the video card for full range levels scripts look the same in al players.
I'll confess that leaves me a bit confused when it comes to your screenshots. From what you've said it appears AvsPmod was displaying the video incorrectly, which VirtualDubMod was getting it right, yet when I look at the "GH2006 A VTS_02_1 extrait.demuxed" sample in MPC-HC, the colours/contrast look very much like your AvsPmod the "GH2006 2" screenshot while the VirtualDubMod screenshot looks too dark. On the other hand, the "GH2006 1" AvsPmod does look a bit washed out, while the same pic in VirtualDub looks better.
I guess from there I'd conclude GH2006 2 is actually pretty good, and just looks too light in AvsPmod because it's not diaplying correctly, and when you adjust it and display it with VirtualDubMod it then looks too dark. GH2006 1 is probably lighter to begin with. Am I on the right track?
I'm getting pretty tired myself but if it helps as a reference, when you save images they should be saved as a full range, because jpgs etc are full range. Therefore there's no expansion to worry about and not much chance the levels of an image will be different when viewed on different PCs. When I save an image it looks exactly as it does when viewing the video in the player, and I'm pretty sure that's correct. If you compare this image to what you're seeing in AvsPmod or VirtualDubMod etc, does it look brighter or darker? It's the first frame of "GH2006 A VTS_02_1 extrait.demuxed.m2v".
Edit: Even now it's being displayed in the browser, the above pic still looks the same as it does when MPC-HC is displaying the video for me. Except the aspect ratio. I didn't bother correcting that for the pic.
Last edited by hello_hello; 15th Oct 2015 at 07:21.
Quote
Similar Threads
-
Advice for fastest x264 settings for Powerpoint lecture transcode
By paukenschlagel in forum Video ConversionReplies: 12Last Post: 31st Oct 2014, 11:30 -
Need Help Choosing Capture Card, TBC, and Software/Settings for VHS/8mm VHS
By Duder_Me in forum Newbie / General discussionsReplies: 1Last Post: 25th Apr 2014, 10:47 -
Choosing right settings for editing HD .mov files in CS4 Premier-PC environ
By Downing32 in forum Video ConversionReplies: 24Last Post: 28th Jan 2013, 17:36 -
Encore CS5.1 ignoring transcode settings on menu
By Killer3737 in forum Authoring (Blu-ray)Replies: 4Last Post: 7th Oct 2012, 18:32 -
Encore 'can't transcode' file set to 'Don't Transcode', won't build ISO.
By koberulz in forum Authoring (DVD)Replies: 0Last Post: 5th Aug 2012, 12:18