dropouts

[eriksen76]

Originally posted by Fr4nz
Hey julius use the MPEG2DEC3 version that is here: http://forum.doom9.org/showthread.php?threadid=74308

Maybe it will fix the problem.

Thanx but as I wrote a few posts ago, I am already using that version. Which Avisynth version are you using?

Maby that could be the error. Well actually Im kinda confused cause it has to be a program related with the rebuilding. Which one is that apart from DVDRB. Cause if I demux the mp2 and ac3 and reauther there are no problems at all???

Im confused.....

/Julius

[Trahald]

maybe jdobbs can comment but since RB is closed environment it can be more picky about input (sorta like the dvd players that have been skipping.. they expect input that is within certain parameters). other authoring apps are like an apex that will accept (actually HAVE to accept) anything remotely acceptable thrown at them and make the output work. its a generalization but its just to give an idea of the difference

[Fr4nz]

Originally posted by eriksen76
Thanx but as I wrote a few posts ago, I am already using that version. Which Avisynth version are you using?

Maby that could be the error. Well actually Im kinda confused cause it has to be a program related with the rebuilding. Which one is that apart from DVDRB. Cause if I demux the mp2 and ac3 and reauther there are no problems at all???

Im confused.....

/Julius

Avisynth 2.54 and 2.55 gave me no problem.

[eriksen76]

Originally posted by Trahald
maybe jdobbs can comment but since RB is closed environment it can be more picky about input (sorta like the dvd players that have been skipping.. they expect input that is within certain parameters). other authoring apps are like an apex that will accept (actually HAVE to accept) anything remotely acceptable thrown at them and make the output work. its a generalization but its just to give an idea of the difference

I think you're right. This evening I tryed to playback one of the RB-Created movies which had stutter in two scenes on my Pioneer and Jvc players. But guess what, their Sony Dvd player did not have any problems at all. Not any freezing either. Just perfect.

So the problem is/or has to be, that DVDRB's output somehow not is / or partly not is compatible with all dvd players. Encoding quality is perfect and sound also. No problems there.

But still the damn periodic stutter on my 2 standalones. Don't know what needs to be fixed to make it work, but lets hope Jdobbs can.

Very very strange that I can demux the output and create a new dvd which plays fine in all standalones. I have never before, until DVDRB, experienced any probs,skips or stutter on my standalone. Dvdshrink, other one-click program backups and downloaded movies all play fine.

...../Julius

[fritzdis]

Originally posted by jdobbs
@fritzdis

Can you outline, step by step, exactly what you did to test this? Are you testing against a full length movie? What audio tracks are you keeping? Did you do any pre or post processing? Versions? I spent 12 hours on this yesterday, scanning files, scanning code, writing testing routines, and testing output. I have only been able to force an audio dropout once -- and this fixed that one.

Make sure you test it on discs other than the test disc -- that one, I believe, is caused by the fact that it is actually growing (not shrinking) during recode.
First, I tried it with the small test disc I made, keeping the 1 audio track. I have now also tested it against a full length movie that had to be reduced to 61.8%. Both the small test disc and the full length movie still display dropouts.

For the movie, I removed 3 of the 4 audio tracks (one of the tracks I removed was DTS). I did not apply any pre or post processing to the title. I used the MPEG2DECdg.dll included in decodefix110mod.zip and dated April 24, 2004, 9:03:24 AM. The Avisynth version is 2.55 (build: Sep 1 2004 [16:49:49]), and the CCE version is SP Trial 2.67.00.27 (along with EclCCE 1.81).

[fritzdis]

Originally posted by jdobbs
DVD-RB assumes it is only being used when making material smaller and uses the original timecodes (only slightly adjusted) from the audio source to determine where to insert on rebuild.
Is this still the case with the new version? If so, do you mean that DVD-RB assumes that the bitrate at every point in the video stream will be less in the reencoded file than in the original? There seems to be no guarantee that this will be the case, especially when the title only needs to be slightly reduced. My post about changing the vbr bitrate to 3000 on my test disc shows an instance where the reencoded file is less than half the size of the original file, yet there are points in the reencoded file where the bitrate is higher than it was in the original.

Originally posted by jdobbs
Make sure you test it on discs other than the test disc -- that one, I believe, is caused by the fact that it is actually growing (not shrinking) during recode.
I think that the case when no reduction at all must be done is not in any way fundamentally different from the case when limited reduction must be done. Obviously, I could be wrong about that, but I can't see what the difference between reduction to 99% and reduction to 100% would be (and DVD-RB should be able to do reduction to 99% even if there would be little reason to actually do it).

Also, for my test disc, the original is 141 MB, and the rebuilt title is 113 MB. This is because DVD-RB decides the original is interlaced, so it sets the max bitrate to 7200 kbps. Out of the three minutes of video, 1 minute is pure black video, which is encoded at almost 0 kbps. Assuming the rest of the video is encoded at the max bitrate, the overall bitrate would only be around 4800 kbps, rather than the specified 6087 kbps.

[gizzin]

jdobbs it was a couple cells into encoding a think the third. I was the whole disc nothing removed at all

[gizzin]

jdobbs, I also have 2 encodes of gang related. One i did one pass and kept everything and it didnt show any dropouts or blips. And one i did 7 pass and removed the other 2 languages with rebuilder bu this one did show dropouts. They were done with v59 so if you were to have these 2 couldnt' you find the problem? I've mentioned this before.

[jdobbs]

@fritzdis

No. It doesn't mean that. Why would the timecodes in the audio be dependent upon the video bitrate? The SCR can be used to determine where is should be so it gets presented within the correct period.

How about we leave the DVD-RB programming to me.

[fritzdis]

The point of my previous post was that if dropouts in my test disc could be "caused by the fact that it is actually growing (not shrinking) during recode," could this not happen on a more localized level? That is, even when the video as a whole shrinks during reencoding, a particular portion of the video could grow and somehow result in dropouts.

[jdobbs]

No, that isn't what I meant. If it is bigger in one place, but overall is smaller or equal it wouldn't make a difference because of buffering and the difference between the read time and the presentation time -- the Audio gets interleaved in the multiplexing and all is well. If however it gets so big (as a whole) that one or the other can't be inserted early enough so that it can be decoded and presented -- you can have a problem. On the original the authoring package would reject it, but since DVD-RB always makes it smaller I never added those checks -- I really don't have to.

There's more to it, but that's it in a nutshell. What I'm saying is that I've spent a lot of time and effort in making this work and work correctly -- and when I say something I really don't expect it to be questioned. The alternative is that I just won't comment at all any more.

[Oldeman]

I still have audio dropouts on three Toshiba players 3950, 4800,and 4900 sing DVD-RB .60 and Quenc .53.

Using 2 pass Quenc give awsome video. It appears to me that the audio /video sync is better with this version. On prior versions it would get horribly out of sync and audio would disapear completely now it seems to pulse, its hard to describe.

As before, I do not get the audio dropouts on my Apex 1500 or Philips DVDR75 or anything done with DVD-RB and Rejig.

[gizzin]

You gonna answer my questions jdobbs? or just keep ignoring

[jdobbs]

Attitude check [yours].... hmmm... yeah, ignore.

[glassvial]

Originally posted by Oldeman
I still have audio dropouts on three Toshiba players 3950, 4800,and 4900 sing DVD-RB .60 and Quenc .53.

Using 2 pass Quenc give awsome video. It appears to me that the audio /video sync is better with this version. On prior versions it would get horribly out of sync and audio would disapear completely now it seems to pulse, its hard to describe.

As before, I do not get the audio dropouts on my Apex 1500 or Philips DVDR75 or anything done with DVD-RB and Rejig.
Wow this thread has grown legs...

Have you tried QEnc .54? Also what version of avisynth are you using? Is what you're backing up PAL or NTSC?

[Oldeman]

I am trying to back up NTSC (NeverTheSameColor) R1 DVD. Using AviSynth 2.54 with DVD2AVIdg/MPEG2DECdg. Tried with/without dynamic bitrates, 1 and 2 pass.

Last time I tried Quenc .54 it died during the rebuild phase. I'm trying it again right now with one pass and .60b(?).

I'm been trying DVD-RB since about version .27(?); never had any trouble with Rejig as encoder.

I have Instant Copy, Ulead Movie Factory 2, Nero Ultra, DVDlab plus most of the freebies..etc. I usually use DVDDecrypter(rip), DeReMake(strip), and DVDShrinkfit), Pinniacle InstantDisk(burn).

System HP 3.0E P4, HP300I burner, WinXP with sp2. Usually burn DVD+R(Ricohjpnr01)4x media at 2.4x. I also burn a lot on my Philips DVDR75 standalone.

[Oldeman]

With Quenc .54 and one pass, I get buffer overflow error#3 during rebuild.
sigh....*&^&$%#

[dragongodz]

Oldeman - since you have a P4 use the mem-aligned version of avcodec. you can download that from the same web page as you got QuEnc 0.54. then you should be able to do 2 pass without it dieing.

[fritzdis]

OK, I'm going to make one last excessively detailed post on this subject. Unless I get an indication that the particular avenue I've chosen is worth pursuing, I'll let it rest after this.

I prepared my test disc with DVD-RB v0.60b, and then using RB-Optv0.15, I changed the Reduction from 100% to 50.2% and saved. I then encoded and rebuilt in DVD-RB and burnt the disc. There was one dropout in each of the final three 45 second chunks, and each was at the same relative position within its respective chunk. The dropout position is marked in blue on this (http://home.comcast.net/~fritzdis/50.2_Reduction.jpg) Bitrate Viewer screenshot of the second 45 second chunk.

Next, I prepared the original test disc again to a different folder. This time I changed the Reduction from 100% to 66.6%, encoded, rebuilt, and the disc had a pair of dropouts in identical relative positions in each of the final three 45 second chunks, as shown in this (http://home.comcast.net/~fritzdis/66.6_Reduction.jpg) Bitrate Viewer screenshot.

Finally, I prepared the original test disc to yet another folder, changed the Reduction from 100% to 85.5%, encoded, and rebuilt. The resulting disc displayed the same dropouts as in my initial description of the test disc (including those in the first 45 seconds), where I had left the Reduction at 100%. Here (http://home.comcast.net/~fritzdis/85.5_Reduction.jpg) is the Bitrate Viewer screenshot of the second 45 second chunk of the 85.5% Reduction file.

All three of these rebuilt discs were smaller than the original test disc.

The obvious assumption one could make when seeing those pictures is that the dropouts are in some way related to the bitrate of the video. Possible reasons that this assumption could be false include (but are not limited to) the following:
1. The use of RB-Opt in some way invalidates the results. This seems unlikely to me, and can hopefully be quickly decided upon.
2. The occurrence of dropouts at higher bitrate spots is coincidental, or (more likely) the higher bitrate is secondary to a more fundamental difference that occurs when encoding with a different average bitrate. This could be particularly difficult to prove or disprove.
3. The source is invalid. The use of pulldown.exe and the fact that DVD-RB decides that the video is interlaced makes me wonder if all the right flags got set. Other questions, such as whether the AC3s created by besweet could be in any way noncompliant, also remain. I have requested that Sir Didymus examine the original files with DVD Profiler, so hopefully he has the time and is kind enough to do so.
4. The artificiality of the video I created and then encoded with CBR (at a bitrate insufficient to handle to most complex parts of video) invalidates the results, at least in a practical, if not theoretical, sense. As far as I know, the material I provided to jdobbs is the only material that has allowed him to reproduce a dropout, so this possibility has to be considered.
5. I have configured something incorrectly or have used a combination of software that introduces errors. Independent rebuilding of the original files would help decide whether this is the case.

[Sir Didymus]

Originally posted by fritzdis
OK, I'm going to make one last excessively detailed post on this subject. Unless I get an indication that the particular avenue I've chosen is worth pursuing, I'll let it rest after this.

...
skip
...

3. The source is invalid. The use of pulldown.exe and the fact that DVD-RB decides that the video is interlaced makes me wonder if all the right flags got set. Other questions, such as whether the AC3s created by besweet could be in any way noncompliant, also remain. I have requested that Sir Didymus examine the original files with DVD Profiler, so hopefully he has the time and is kind enough to do so.

...
skip
...


That's right, I have available yours source files. Thank you. ;)
Only now I have some time to get a look at them...

Please consider that the already stated questions regarding the fact that their size is less than a DVD-R, and so about the necessity of using specific tuning of the cell bitrate, should be not underestimated...

I am afraid my spare time is very limited in this timeframe, but I will be happy of verifying your source with the profiler.

Regarding the usage of pulldown, please consider that I am from PAL land, so I am definitely not able to tell if it should be used or not...

Anyway I say again, I will post later the profiler output on your source files...

Cheers,
SD

[Sir Didymus]

@fritzdis

Here is the analisys of your SOURCE title.
In the attached archive, the error.jpg reports the synthesis of the whole profiler work, with error id's and relative occurrencies.

Giving a very quick look at the error logs, the most important reported ones are #1691, #1696, #1697.
Of course all errors are important, but #1000 are all MPEG errors...

Just as examples,
#1691 is a VBV buffer overflow;
#1696 is an error in the Vbv_delay value, leading to negative or zero time to receive all bits of previous picture;
#1697 reports that the actual bit_rate exceeds maximum bit_rate, as specified in sequence header and sequence extension.

In the same archive, the std buffer.jpg shows the real time occupancy of the std buffer. In this case, as you may see,
the figure is very good, since it shows that the system target decoder buffer is most time full (i.e. over 200000), but IT NEVER OVERFLOWS the limit [which is 237568]...

I will send to you, via PM, other more detailed log information, with the extensive description of all detected errors...

Cheers,
SD


P.S.

I should say that it seems that too many variables have been put in the process and, as you see, many errors are present in the source title...

So, please consider that using this specific source for trying to understand what is going wrong with DVD-RB may be not totally helpful for jdobbs, even if yours (and myselfs, and other kind testers) idea is to try to provide him with useful and supporting information...

Even original titles have errors, but at least, since they are available on the shelf, DVD-RB should try to cope with them, otherwise the backup of these originals would be precluded.

Even in the case of a completely error free source [and I state clearily, I will give full support to you, if you like, for improving the source], there is still the big problem that DVD-RB is assumed to be used for reducing titles larger than 4.700.000.000 bytes, so whatever errors we get in the rebuilt target, we will never be able to state the logical conclusion that something is wrong in DVD-RB...

I mean, maybe it should be better to base further analysis on original titles... What do you think about ?

[fritzdis]

Originally posted by Sir Didymus
Even in the case of a completely error free source [and I state clearily, I will give full support to you, if you like, for improving the source], there is still the big problem that DVD-RB is assumed to be used for reducing titles larger than 4.700.000.000 bytes, so whatever errors we get in the rebuilt target, we will never be able to state the logical conclusion that something is wrong in DVD-RB...
Do you think using RB-Opt to adjust Reduction makes any difference in what logical conclusion we can draw? I could of course take the three minutes of video and audio I have now and turn them into two hours, thus constructiing a title greater than 4.700.000.000 bytes, but distributing that source would then be too difficult.
Originally posted by Sir Didymus
I mean, maybe it should be better to base further analysis on original titles... What do you think about ?
The main reason I remain fixated on my test disc is that, as far as I know, it is the only material that has allowed jdobbs to reproduce dropouts, and it must be incredibly difficult for him to fix errors that don't even happen to him. [Edit: The other reason I'm fixated on my test disc is the striking correlation between bitrate and dropouts that seems apparent from the screenshots of the reencoded files done at different reductions. Results this "clean" may be hard to find without a controlled source.]

All of this may not matter though, since the source files display so many errors. At this point, I want to let jdobbs direct me as to whether any further testing could yield any helpful results.

[Sir Didymus]

Originally posted by fritzdis
Do you think using RB-Opt to adjust Reduction makes any difference in what logical conclusion we can draw?

No, I don't think it will change too much, beside it is an additional process/tuning/action added to the process, so it could make more difficult to state by sure if it is really relevant or not...

Originally posted by fritzdis

I could of course take the three minutes of video and audio I have now and turn them into two hours, thus constructiing a title greater than 4.700.000.000 bytes, but distributing that source would then be too difficult.

Totally agreed. It could help a lot for removing any additional intervention, once the source title is generated, but it will be very difficult to share it...

Originally posted by fritzdis

The main reason I remain fixated on my test disc is that, as far as I know, it is the only material that has allowed jdobbs to reproduce dropouts, and it must be incredibly difficult for him to fix errors that don't even happen to him. [Edit: The other reason I'm fixated on my test disc is the striking correlation between bitrate and dropouts that seems apparent from the screenshots of the reencoded files done at different reductions. Results this "clean" may be hard to find without a controlled source.]

Your work is really appreciated [at least I can say this for what is concerning myself]. Since in the last two days two DVD-B releases have been released, I suppose that they have been very useful also for jdobbs... But I'd better speaking just for myself...

Originally posted by fritzdis

All of this may not matter though, since the source files display so many errors. At this point, I want to let jdobbs direct me as to whether any further testing could yield any helpful results.
I say again, sometimes even original titles are showing plenty of errors, so please do not stop your tests just because of the reported errors; please follow the indications of jdobbs [if any will be given].

By the way, is anybody able to see the attachment I put on my previous post ? It is a zip archive of just 80KB, that for some mystic reasons seems to be not visible to me... And it should be there due to the bulletin is preventing me to attach it again to another post...

Cheers,
SD

[Oldeman]

In my last run whereby I reported dropouts, I discovered that I was not using .60b due to a browser cache issue.

I just finished a SUCESSFUL movie using DVD-RB .60b and Quenc .54 with memaligned avcodec. This movie plays without audio dropouts on my Toshiba players. This is a first for me with DVD-RB and Quenc.

My thanks to you M.JDobbs and to dragongodz for suggesting the P4 workaround (memaligned avcodec).

I will test a different movie to verify, but I think you might have a good fix on the audio dropouts. At least for some more players.

DVD-RB is a very complex effort, using pieces of other peoples software and trying to handle an almost infinite number of varibles (in the bastardizied dvds that are available) plus being hacked again by each user. Its amazing that it works at all.

Congrats JDobbs, don't be so hard on yourself. Just because a few of us are having difficulty with your fantastic software..

Its a noble cause and you're the MAN...:)

[fritzdis]

SD,
[Edit: Now I see the attachment]

[wmansir]

I approved your attachments, Sir Didymus.

In the future you can PM me when you post an attachment.

Also, you can host image (and .swf) files for free at:

http://www.imageshack.us/index.php

[eriksen76]

This is the info that is written on my scene where I get a dropout.
Could something below cause it. As you can see its for the hole title (V01000100001002. But I only see error after about 2 mins.

What does this mean???? : *samples_per_sec=44100
Is it downsampled or what?????? Thought it was 48000

Does everything look ok?

[item]
title=V01000100001002
aud_out=0
vaf_file=C:\DOCUMENTS AND SETTINGS\ ERIKSEN\SKRIVEBORD\D2VAVS\V01000100001002.vaf
aud_file=C:\DOCUMENTS AND SETTINGS\ ERIKSEN\SKRIVEBORD\D2VAVS\V01000100001002.mpa
file_focused=0
packet_size=2048
width=720
height=480
frame_rate_idx=1
cbr_brate=6000
vbr_brate_avg=3345
vbr_brate_min=0
vbr_brate_max=9000
seq_endcode=0
dvd=0
half_width=0
half_height=0
lum_level=0
aspect_ratio=2
gop_m=3
gop_nm=4
gop_hdr=12
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
*samples_per_sec=44100
stereo=2
brate_idx=7
crc=1
progressive=1
alternate_scan=0
intra_dc_prec=2
aud_mode=0
tc_ref_frm=0
drop_frame=0
fix_vbv_delay=0
letter_box=0
pulldown_detect=0
offset_line=0
create_new_vaf=1
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
dither=0
dither_max=8
qmat_idx=0
quality_prec=16
timecode=0x0000000
q_char_f=16
tc_offset=0
v_filter=0
v_filter_val=6
pict_name=
pict_type=3
pict_level=255
video_type=16
vid_file0=C:\DOCUMENTS AND SETTINGS\ \SKRIVEBORD\D2VAVS\V01000100001002.m2v
vid_file1=C:\DOCUMENTS AND SETTINGS\ SKRIVEBORD\D2VAVS\V01000100001002.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=9000
vbr_bias=10
vbr_pass=5
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1

[file]
name=C:\DOCUMENTS AND SETTINGS\SKRIVEBORD\D2VAVS\V01000100001002.avs
frame_first=0
frame_last=21826
encode_first=0
encode_last=21826

Julius

[robot1]

Originally posted by eriksen76
This is the info that is written on my scene where I get a dropout.
Could something below cause it. As you can see its for the hole title (V01000100001002. But I only see error after about 2 mins.

What does this mean???? : *samples_per_sec=44100
Is it downsampled or what?????? Thought it was 48000

Does everything look ok?

[item]
title=V01000100001002
aud_out=0
Audio is not encoded (aud_out=0), so it's not downsampled.

[fritzdis]

I've done two new tests with v0.62

First, I created a 5.29 GB dvd out of my test video. I then used DVDRB in one-click mode on that title and burned the result. There were dropouts in mostly the same places as my other tests (this time, I had reduction=79.8%, which is in between 2 of the previous tests I had done with small titles; those tests gave me better consistency in terms of dropout placement).

Next, I did a test that was suggested to me by robot1. With my small title, I ran the prepare stage. I used RB-Opt to set reduction to 85.5%. Then, in REBUILDER.ECL, I changed dvd=0 to dvd=1 (this is the DVD Compliant setting, right?). Then I encoded and rebuilt. The burned disc had the dropouts in exactly the same places as before (in fact, the dropouts seemed worse; that is, the duration of each dropout seemed slightly longer, but it could be my imagination).

If anyone thinks there are other tests I could run to more surely validate my results, let me know. The only thing I can think of is making a disc greater than 4.37 GB that DVDRB would decide needs to be reduced to about 85.5%. Then I could compare that result with my smaller test at 85.5%. I may do that overnight tonight.

[Sir Didymus]

Originally posted by fritzdis
I've done two new tests with v0.62

First, I created a 5.29 GB dvd out of my test video...



Hi, fritzdis...

Happy to ear this. In fact [I mean, just in my opinion] the relevance of testing DVD-RB on a title that is not fitting anymore on a DVD-R is now much improved...

Cheers,
SD