View Full Version : Image corruption
PhilippeB
2nd November 2009, 17:58
I am experiencing random image corruption in the process of Making a blu-ray movie-only. This may happens a couple of times in a whole movie. The rest of the video seems okay.
Here are my steps so far:
- Rip VC-1 or h264 movie in .iso / folder using AnyDvdHD latest trial
- Open in BD ReBuilder 0.31 (or AVCHD Coder)
- Proceed with 'Movie only' conversion keeping both (best) English and French tracks (no audio reconversion) and highest quality settings (7 hours or so)
- Burn to BD-R / RE (25G) with Img Burn @ 4x / 8x.
- Play on Sony BDP S550.
I saw the effects are present on the files BEFORE burning them (playing the resulting m2ts file with power dvd) so it is not a burning issue. Since it happens (more with VC-1, Less with h264) i though this could be a codec issue.
in FFDSHOW, the h264 codec shows as 'libavcodec'. The VC-1 codec had been tried with both 'WMV9 and libavcodec' settings without significant differences.
If i re-encode a movie many times, the artifacts will moove in time (a previously corrupted scene will be okay while another that was okay will become corrupted).
Attached are examples of the image corruption i am experiencing.
I Run Win7 + i7 950 (I know Win7 not supported by Rebuilder but hey - that's the only OS my new machine will take).
Any hint would be greatly appreciated.
:thanks:
jdobbs
2nd November 2009, 18:43
The only time I've seen that sort of thing is when there is a bad rip. It used to happen on some older versions of AnyDVD.
setarip_old
2nd November 2009, 19:09
@PhillipeB
Hi!
I've seen similar "activity" with extremely mildly dirty or scratched discs, or a player/reader in need of cleaning...
laserfan
2nd November 2009, 19:39
I had similar issues of very random, and relatively few, pixelations; sometimes just one or two, always fewer than a half dozen instances per movie, each of which lasted only 1-3 frames. These completely went away when I acquired an Nvidia graphics card and started using neuron2's DGIndexNV tools to do all my encoding. I decided in my case the previous random pixelations must have been decoding issues.
PhilippeB
2nd November 2009, 20:38
Most important is that the initial RIP is GOOD. Whatever player i play it in, corruption isn't there.
It is just after re-sizing the original rip it that it becomes that ugly.
I'm starting to doubt my disk controller at this point. Asus still haven't release their Win7 driver disk so far grrrr :devil:. Hope to get that in place soon and come back with some positive news.
:thanks:
jdobbs
2nd November 2009, 21:14
Most important is that the initial RIP is GOOD. Whatever player i play it in, corruption isn't there.
It is just after re-sizing the original rip it that it becomes that ugly.
I'm starting to doubt my disk controller at this point. Asus still haven't release their Win7 driver disk so far grrrr :devil:. Hope to get that in place soon and come back with some positive news.
:thanks:How do you put the rip in a player to test it? A BD-50 RE? Or are you talking about software players?
PhilippeB
2nd November 2009, 22:17
Software player (I mentionned above Power DVD from cyberlink as example). Nero showtime also. There are plenty.
I actually have no 50G BD-RE, only a 25G.
jdobbs
2nd November 2009, 22:36
Software player (I mentionned above Power DVD from cyberlink as example). Nero showtime also. There are plenty.
I actually have no 50G BD-RE, only a 25G.Can you do me a favor? Can you open the AVS file (assuming it still exists) that contains that scene with Media Player Classic or Windows Media Player and see if it is the decoder that might be at fault? If it is, that scene should show the pixelation during playback of the AVS.
setarip_old
2nd November 2009, 22:51
I just noticed that you say:Open in BD ReBuilder 0.31 (or AVCHD Coder)Are you seeing this pixelation ONLY when you use BD-RB, or does it also occur when you instead use AVCHDCoder?
If it happens with AVCHDCoder, I'd suggest that it's not a problem with BD-RB. Rather, I'd soonser suspect a hardware or system software problem...
PhilippeB
3rd November 2009, 02:01
Actually, it looks like the problem is elsewhere.
RAM checks out ok in MEMTest86+. Did some little test with seatools and all the harddrives seems fine.
Finally, i remuxed Ratatouille with TSMuxer and kept only the PCM english track, the AC3 french track and of course the AVC.
The corruption occured around time index 25:xx. Since this operation involves no decoding / encoding, basically, it is just filecopy / repackaging, i'm surprised.
I attached a frame of the result (be carefull, this might hurt !)
:eek:
setarip_old
3rd November 2009, 06:25
@PhilippeB
Once again:
Are you seeing this pixelation ONLY when you use BD-RB, or does it also occur when you instead use AVCHDCoder?
PhilippeB
3rd November 2009, 22:23
@PhilippeB
Once again:
Are you seeing this pixelation ONLY when you use BD-RB, or does it also occur when you instead use AVCHDCoder?
Anytime, anywhere. Like i just posted yesturday (yup ! This one was to answer your question) it happens even if i only RE-MUX.
So far, the problem is down to TS-Muxer. I am going to try tonight to do multiple copies across drivers to see if i can reproduce it.
:thanks:
PhilippeB
4th November 2009, 02:13
*Fresh news* di one last test tonight to confirm the problem is with tsMuxer: I copied around my 4 drives an original RIP and listen to it and no corruption. So it really happens in tsMuxer (which is a tool i believe both BD-Rebuilder and avchd are invoking).
So the 1000$ question, what is tsMuxer doesn't like about my machine (but i guess i should start another thread for this one).
For sure, it is win7 (RC7100). It is a verry fast machine (i7950 + mushkin 6-7-6-18 @ 1600).Also the drives are really fast (110, 120 and 205 Mb / s sustain transfer).
I think i may hit a condition with tsMuxer that nobody had before ?
deank
4th November 2009, 12:19
You can try again, but setting VBV Buffer size, ms: [1000]ms and see if it will make a difference.
Do you see any errors in the log (like buffer overruns/overflows) when processing the title?
PhilippeB
5th November 2009, 00:29
Thank you for the feedback. I tried this tonight with big hopes but unfortunatly, got a bad frame around time index 0:22 = (
I attached the frame. The legs we see in the bottom are Sandra Bullock's = ) but they happen BEFORE the plane. The plane happen after. weird.
jdobbs
5th November 2009, 01:10
Thank you for the feedback. I tried this tonight with big hopes but unfortunatly, got a bad frame around time index 0:22 = (
I attached the frame. The legs we see in the bottom are Sandra Bullock's = ) but they happen BEFORE the plane. The plane happen after. weird.What I can't understand is why this is only happening to you? Is there anything unique about your system or configuration?
setarip_old
5th November 2009, 02:00
@PhilippeB
Check for overheating (and gunk/dust bunnies) and/or less than perfect connections and seating of cards...
PhilippeB
5th November 2009, 02:20
What I can't understand is why this is only happening to you? Is there anything unique about your system or configuration?
Because i have a bad Karma i guess = (. The worse part is that i bought a whole new system with top of the notch configuration to be able to play with HD and it is 3 months so far i cannotenjoy it bou-hooouuuu ! : )
PhilippeB
5th November 2009, 02:27
@PhilippeB
Check for overheating (and gunk/dust bunnies) and/or less than perfect connections and seating of cards...
I assembled everything myself so pretty sure about averything - 20 years in HW engineering makes the guy pretty paranoiac : ).
If there was something loose, this would occur system failures other than in tsMuxer and so far, i cannot complain i have less than a blue screen a week and its almost running 24/7.
Win7 is the most stable OS i've seen so far (the other one being XP but even then, XP was not as stable when it got out at first).
I sent an email to the tsMuxer team reporting every test ive done with some screen captures. Hope they'll get it and take it seriously.
setarip_old
5th November 2009, 02:32
I'm sure that with your 20 years' experience, you are very familiar with both "Murphy's Law" and the phrase, "Better safe than sorry".
Have you checked for overheating?
neuron2
5th November 2009, 03:15
@PhilippeB
Please use a hosting site for multiple large images.
PhilippeB
5th November 2009, 14:50
I'm sure that with your 20 years' experience, you are very familiar with both "Murphy's Law" and the phrase, "Better safe than sorry".
Have you checked for overheating?
So far, the Mobo stays cool around 36ºC. Also the CPU is at 38 ºC under normal load. Under heavy load the cpu top at 72ºC. The hard drives range between 35 and 39ºC depending on the drives (i have one sas @ 15K, the others are SATA @ 7.2K).
I played again with that setting in tsMuxer and putted it to 0. I'm going to watch the movie again tonight to see if it's worse, same or better.. we'll se.
Thanxs everybody for the moral input = ) :thanks:
jdobbs
5th November 2009, 16:59
I assembled everything myself so pretty sure about averything - 20 years in HW engineering makes the guy pretty paranoiac : ).
If there was something loose, this would occur system failures other than in tsMuxer and so far, i cannot complain i have less than a blue screen a week and its almost running 24/7.
Win7 is the most stable OS i've seen so far (the other one being XP but even then, XP was not as stable when it got out at first).
I sent an email to the tsMuxer team reporting every test ive done with some screen captures. Hope they'll get it and take it seriously.Definitely odd. You don't, by chance, have the "screw up image" setting enabled in TSMUXER do you? :)
GaPony
5th November 2009, 22:22
So far, the Mobo stays cool around 36ºC. Also the CPU is at 38 ºC under normal load. Under heavy load the cpu top at 72ºC. The hard drives range between 35 and 39ºC depending on the drives (i have one sas @ 15K, the others are SATA @ 7.2K).
I played again with that setting in tsMuxer and putted it to 0. I'm going to watch the movie again tonight to see if it's worse, same or better.. we'll se.
Thanxs everybody for the moral input = ) :thanks:
72C is plenty hot enough to get some instability unless you're using an old Pentium D series processor... The newer CPUs shouldn't be anywhere near that. The Core i7-950 has a max operating range of 67.9C.... according to Intel's data.
PhilippeB
6th November 2009, 03:01
72C is plenty hot enough to get some instability unless you're using an old Pentium D series processor... The newer CPUs shouldn't be anywhere near that. The Core i7-950 has a max operating range of 67.9C.... according to Intel's data.
Anyways temperature is not the issue here since tsMuxer doesn't draw any power from the CPU. Actually lookin' at it doing its thing and it is at a mere 38-39ºC.
However, not having worked on the i7 design team, what i read from it was quite interesting. It got its own 'over clocker' processor that counts as many transistors that there were on a 486. Its only purpose is to add overclock steps as task load needs it taking into account cpu#, temperature, current etc. It probably knows its own limit and where to stop.
When i don't do anything with my machine, CPU-Z shows a 1603Mhz CPU. But when i am encoding something, it goes up to 3207Mhz by itself (my i7 950 base frequency is 3.07Ghz btw). Do nothing. I am not overclocker (always been against it) so thats why i read alot about the mecanism. Also, you see VCore that jumps from 0.94V to 1.23V what is, again, normal (everything's under control) and CPU fan will speed up to compensate etc.
I love this machine ! = )
PhilippeB
6th November 2009, 03:03
Definitely odd. You don't, by chance, have the "screw up image" setting enabled in TSMUXER do you? :)
Man ! I knew i should have let that one checked out !
I think i'm going to have to write my own tsMuxer with enough critical sections so threads don't bounce one into another...
Are you more the Visual Studio type or borland ?
GaPony
6th November 2009, 03:38
So far, the Mobo stays cool around 36ºC. Also the CPU is at 38 ºC under normal load. Under heavy load the cpu top at 72ºC. The hard drives range between 35 and 39ºC depending on the drives (i have one sas @ 15K, the others are SATA @ 7.2K).
I played again with that setting in tsMuxer and putted it to 0. I'm going to watch the movie again tonight to see if it's worse, same or better.. we'll se.
Thanxs everybody for the moral input = ) :thanks:
You're the one who reported the 72 degree reading. If you're not getting near 100% load when using BD-Rebuilder, there's something not working right.. so which is it? There is most likely something going on that's unique to your PC, since I haven't seen this issue put forward by anyone else, anywhere in this forum.
PhilippeB
6th November 2009, 13:29
You're the one who reported the 72 degree reading. If you're not getting near 100% load when using BD-Rebuilder, there's something not working right.. so which is it? There is most likely something going on that's unique to your PC, since I haven't seen this issue put forward by anyone else, anywhere in this forum.
<Sorry for taking this place, i know it's in the wrong thread, but let me explain to the guy>
It's because you read too fast or don't get everything i said straight. The problem i am experiencing is caused by tsMuxer USED by BD-Rebuilder during its process. tsMuxer is basically like doing a 'filecopy' in dos, but selecting which part of file you whish to keep. So this shouldn't load your CPU doesn't it ?
For thoses who havent realized this yet, BD-Rebuilder is a user interface, a really cool one by the way. It does no magic, it only automates tasks for you you would normally have to do by hand. It also does a bit of math so you don't have to calculate audio size to figure out what vdo should be compressed to.
Ok. i7 CPUs (and more likely with win7 who has a more agressive way of managing energy than vista) have, as normal behaviour, to jump from a clock speed to another when task load requires it. This is plenty documented over the net - look for it. This part happens when BD-Rebuilder invokes x264 (the encoder). My problem is happening BEFORE that, when it invokes tsMuxer (figure that you must have to split a transport stream first if you want to re-encode the h264 part it contains). Then after, everything is packed back together by txMuxer again. So double the image corruption for me.
My problems are comming from tsMuxer. Why ? I don't know. Am i the only one with this problem ? Certainly not ! I downloaded 'Deep Impact' full BD rip (2 english tracks + chineese) from torrent and saw the exact same artifact i am experiencing in the middle of the movie, when Morgan Freeman addresses the US to say they all going to die (but that's another story).
There is probably a load bunch of you out there experiencing the problem without knowing it, most likly because peoples don't even look at the movies they repackaged. They read the guide and assume because they did everything right it should be okay if the few first minutes seems fine - EEEEEEEEEERRRH ! sorry, try again !
For the 72ºC, i wouldn't worry too much. Like i said, i7 have their very own processor DEDICATED to clock control, self-overclocking, heat control, voltage tweaking etc. so nothing is going to be unstable here. Look at tomshardware.com for more details on the topic.
Also watch out the new i5 out there, they have also the same behaviour but even pushed more to the limit making them interesting for that because they can almost compete with the i7 in term of processing power, at a much lower price. Of course with limited RAM bandwidth due to the 2-way instead of 3.
:)
jdobbs
6th November 2009, 14:11
Man ! I knew i should have let that one checked out !
I think i'm going to have to write my own tsMuxer with enough critical sections so threads don't bounce one into another...
Are you more the Visual Studio type or borland ?Visual Studio.
For thoses who havent realized this yet, BD-Rebuilder is a user interface, a really cool one by the way. It does no magic, it only automates tasks for you you would normally have to do by hand. It also does a bit of math so you don't have to calculate audio size to figure out what vdo should be compressed to. I couldn't disagree with this more. It contains several thousand lines of code that modifies things that you couldn't do by hand in several lifetimes... It recreates the MPLS files, modifies M2TS files, scans and corrects timing in M2TS files when required, and about a hundred other functions. I would challenge you or anyone else to do just one full disc backup without BD Rebuilder that works.
No hard feelings -- I'm just tired of having several months of work marginalized by those who just don't understand the complexity involved. If it was simple, BD Rebuilder wouldn't still be the ONLY full disc BD backup in existence 10 months after its release.
deank
6th November 2009, 14:41
tsMuxer is basically like doing a 'filecopy' in dos, but selecting which part of file you whish to keep. So this shouldn't load your CPU doesn't it ?
For thoses who havent realized this yet, BD-Rebuilder is a user interface, a really cool one by the way. It does no magic, it only automates tasks for you you would normally have to do by hand. It also does a bit of math so you don't have to calculate audio size to figure out what vdo should be compressed to.
jdobbs already answered to the second paragraph of the quote, but I'll also add that tsMuxeR doesn't do ANYTHING close to file-copy (with or without the quotes around "filecopy"). I have a lot of respect to the guys at SMlabs and jdobbs, too - they've done something for free, which no one else did (not even as a payware).
Because you already mentioned that you downloaded a blu-ray rip from the internet, I'm sure further discussion is not allowed. Still one thing you can try with your original blu-ray title (ripped to your hdd) is to use tsMuxeR and CUT START/CUT END the part of the original video where the problem occurs and see if frames will be broken again (i.e. do not remux the whole thing, just few minutes of it).
Dean
PhilippeB
6th November 2009, 16:17
Hey guys - don't want to hurt any feeling and sorry if i did so. I am an enthusiast myself and don't count the lines of codes i have written in my life. I simply adore that.
I don't complain about the tools, just trying to figure out a way (if any way it is) to make them work in my configuration.
I did indeed downloaded a rip (thus that might not be in the spirit of the forum) to introduce another 'source' in my tests to see a difference. BTW i honestly deleted it yesturday night when i saw it was corrupted as well.
Will do some more work next week on another computer (let's say a basic model P4 1.5 with XP) and see if i can get different results. Keep you gang posted.
Again, no hard feelings i hope, you seem like a verry funny gang and i would like to stick around.
PhilippeB
6th November 2009, 17:42
Still one thing you can try with your original blu-ray title (ripped to your hdd) is to use tsMuxeR and CUT START/CUT END the part of the original video where the problem occurs and see if frames will be broken again (i.e. do not remux the whole thing, just few minutes of it).
Dean
Then again, each time i pass the same original BD movie ripped to my HD through tsMuxer, i will get the error at random places (never at the same place).
Yet i am not insane (not that i'm aware of anyways) the problem IS there. I will find what is causing it and let you guys know what it was.
Thanxs for the interest.
setarip_old
6th November 2009, 19:10
@PhilippeBIf i re-encode a movie many times, the artifacts will moove in time (a previously corrupted scene will be okay while another that was okay will become corrupted).Then again, each time i pass the same original BD movie ripped to my HD through tsMuxer, i will get the error at random places (never at the same place).
If instead, you re-encode the rip ONLY ONCE and play it back several different times (CLOSING the player after each time played) does the pixelation occur at the same place each time?
PhilippeB
7th November 2009, 16:59
@PhilippeB
If instead, you re-encode the rip ONLY ONCE and play it back several different times (CLOSING the player after each time played) does the pixelation occur at the same place each time?
Yess ! The corruptions is always there at the same place, whatever i listen to it in Power DVD or i burn it to a a BD-RE and listen to it in my Home theater player.
If a remux the original source a second time, previous crap won't be there anymore but new ones will appear at a different time index. Once again, if i play on the computer or in the home theater.
PhilippeB
7th November 2009, 20:40
JDobbs, is there a way for me to customize the command line BD-RB uses to invoke tsMuxer (or at least add an option to the command line that will be effective each time BD-RB invoke tsMuxer ?)
thanxs !
turbojet
7th November 2009, 22:34
Have you tried disabling speedstep in bios?
PhilippeB
7th November 2009, 23:27
Have you tried disabling speedstep in bios?
Humm.. I didn't know what speedstep was so i went to look around for info. They say it is a laptop fuction to be energy-wise while on battery (loose performance). Peoples seems to say it doesn't apply to desktops (does it ?). Also i saw it was supported by some old os (98, ME, XP (with some patches)). I am running 7.
Is it possible speedstep is an old old thing not actual anymore ?
thanxs
turbojet
7th November 2009, 23:51
No idea where you are a getting your information from but speedstep has been on all intel motherboards for 5+ years now just like amd cool n quiet. Speedstep is what is throttling your cpu by changing the cpu multiplier between 1.6ghz (8x) and 3.2ghz (16x) in your situation unless you are using some software for that. Speedstep isn't dependent on OS and works with any or no OS.
While CPU throttling is good in practice it can be buggy when switching modes. It has very little benefit when using AC power but it helps a little to extend a batteries life.
Groucho2004
8th November 2009, 09:48
Speedstep isn't dependent on OS and works with any or no OS.
This is wrong. Speedstep as well as the various CPU Halt states have to be supported by the OS and they need specific drivers to work. Same for CnQ. Just enabling these in the BIOS isn't enough.
Where do you get your information from?
deank
8th November 2009, 09:55
Actually, it looks like the problem is elsewhere.
The corruption occured around time index 25:xx. Since this operation involves no decoding / encoding, basically, it is just filecopy / repackaging, i'm surprised.
I think it is a good idea to try 2 other things:
1) Use the same ripped folder and process it on another computer
or
2) try to use eac3to to remux main movie to mkv (or demux it) and see if the source will be damaged again.
Dean
PhilippeB
8th November 2009, 18:24
Oki - I found the speedstep thing in the BIOS. I disabled it and tried again to remux with default settings - i got the corruption in the early stages of the movie. No luck.
I am working on the other tests suggested by deank. Keep in touch.
:thanks:
PhilippeB
9th November 2009, 17:53
I think it is a good idea to try 2 other things:
1) Use the same ripped folder and process it on another computer
or
2) try to use eac3to to remux main movie to mkv (or demux it) and see if the source will be damaged again.
Dean
1) Transferred 1h46 movie @ pedestrian speed of 11MB/s to my old P4 running XP (convinced me to buy a gigabit router) and tsmuxed it there, then brought back to my i7 (again at pedestrian speed) for playback. The result ts file was 100% ok.
2) Used Clown_BD as a frontend to eac3to specifically say NOT to use tsMuxer. The resulting h264 file was 100% as well.
Next thing i am going to remux the resulting eac3to demuxed files with tsMuxer on my i7 and let you know the results this afternoon.
So far, i understand what i already knew that tsMuxer works on old computers / XP (maybe vista) but maybe not so well on newer i7 / win7 / too fast computer. I also notice eac3to seems not to fear my i7 and works perfectly.
deank
9th November 2009, 20:20
At least now you know where the problem is :)
Good luck!
Dean
jdobbs
9th November 2009, 20:22
This is way too odd. For the life of me, I can't figure out why there would be corruption with TSMUXER on one computer and not on another. Does anyone know if TSMUXER is multi-threaded? I've had no issues, though, on my AMD quad-core.
PhilippeB
9th November 2009, 20:44
This is way too odd. For the life of me, I can't figure out why there would be corruption with TSMUXER on one computer and not on another. Does anyone know if TSMUXER is multi-threaded? I've had no issues, though, on my AMD quad-core.
Would that be possible to have BD-Rebuilder use eac3to instead of tsRemuxer ? (i don't think it can remux right ?)
:thanks:
BTW this was a joke for thoses who didn't understood
setarip_old
9th November 2009, 20:49
@PhilippeB Would that be possible to have BD-Rebuilder use eac3to instead of tsRemuxer ? (i don't think it can remux right ?)Since you appear to be the ONLY person at these forums (and, perhaps, the entire world) experiencing this problem, I think it's a bit much to ask the author to alter BD-RB's structure/program usage...
Capsbackup
9th November 2009, 22:32
I use an I7 920, with XP Pro, and never had an issue like this. Perhaps more attention needs to be placed on the OS, Windows 7!
@PhilippeB;
It may be time for you to try either XP or Vista, which have been used and proven completely compatible with BD-RB. Then you can see if Windows 7 and its associated codecs used are at fault. :confused:
PhilippeB
10th November 2009, 02:58
Setarip_old, if you read the thread above i saw the same image corruption present in some BD-rips in torrents over the net (torrents i got rid of since the image was corrupted anyways). So no, i'm not the only one in the universe ;) At first peoples believe earth was flat but it wasn't... wasn't it ? The problem exists, hiding from it or not admitting it won't change anything. I only try to bring up solutions (isn't that the purpose of forums ?)
Win7 might be involved but unfortunatly, its the only OS that will install to this machine. I tried again and again with vista 64 for 3 days reformatting over and over and service packs won't install due probably to the hardware. This was a full legit 64 bit ultimate version btw. Anyways everybody told me Vista was crap so why bother. 7 runs extremely smoothly, better OS i had in my life. Wouldn't change it for anything.
XP was nice but it handles only 3G of RAM, i have 6 and 6 more on the way so let's forget about it.
**More test results** I remuxed the files demuxed with clownBD/ea3cto with tsMuxer and everything went fine (no image corruption) so it looks like the corruption comes from the demuxing part of tsMuxer (on my machine and probably others very fast machines).
I leave you with that. So far, i have a complex (not to say pain in the ass) path to perform BD-Rebuilder job by hand doing as follow:
ClownBD/eac3to -> Ripbot264/x264 -> tsMuxer -> imgburn -> BD25.
For some of you this might be like going 25 years in the past but for me it means being able to burn my first crap-less BD ! :p
Capsbackup, i plan to buy my win7 soon (still on the RC 7100 version) so i can install the XP SP3 patch in there (dont' ask me why but it won't accept to install over RC7100 even if i got it the right way registering through M$) so i might be able to access what has seem to be accessible to everyone here.
thanxs
GaPony
10th November 2009, 07:31
I can't imagine any hardware you might have that would prevent you from installing Vista (64 or 32 bit versions). Any hardware on the market today was most likely to be thoroughly tested with Vista, since Windows 7 was only just released on 9-22-2009.
Maybe you need to wipe out the partitions before installing it. A simple format may not be enough, but I never had any trouble installing and reinstalling between Vista Ultimate 64 and the Win 7 RC. I'm only using a Q9560, but there's nothing special about the i7 architecture. There are thousands, if not millions, of i7 PCs running on Vista.
Its right in the beta instructions (to include the RC) that the beta version will have to be removed and you'll have to do a reformat and clean install of whatever OS you move to.
setarip_old
10th November 2009, 07:58
@PhilippeB
I'm sincerely glad that the workaround resulting from the suggestions by "deank" now allows you to avoid your problem.
On the other hand:Setarip_old, if you read the thread above i saw the same image corruption present in some BD-rips in torrents over the net (torrents i got rid of since the image was corrupted anyways). So no, i'm not the only one in the universe At first peoples believe earth was flat but it wasn't... wasn't it ? The problem exists, hiding from it or not admitting it won't change anything.Yes, I read that post - and offer the following:
1) Despite the many, many conversions (of legitimate, commercial BluRay discs) created by members of this forum performing beta testing of BD-Rebuilder, other than yours, there's been not one instance of untoward momentary pixelation reported - and from what I've read, no such reports regarding RipBot, AVCHDCoder, or other similar "packages" that incorporate the use of tsMuxeR.
2) Just as with a member reporting a "bug" in BD-RB based on using a rules-violating download (including "torrents") rather than a legitimate commercial BluRay disc as a source, members are advised that doing so is inappropriate and the report will be disregarded, as it is presumed that such source material cannot to be relied upon.
3) Although you initiated this thread in the sub-forum exclusively for DVD Rebuilder and BD Rebuilder, you appear to be convinced that your problem lies with tsMuxeR. Then perhaps it would make sense for a moderator to move this thread to the "(HD) DVD & Blu-ray authoring" sub-forum - and perhaps join it to the tsMuxer-specific thread there.
4) You have just now mentioned that your are also having rather unusual OS installation problems. My personal opinion is that you (and only you) have too many uncertainties involved to continue to ask members to attempt to pinpoint the exact cause of your exclusive (At the Doom9 Forums) problem.
5)You mean the Earth ISN'T flat? Maybe that's the cause of your pixelation ;>}
PhilippeB
10th November 2009, 15:33
Yes, this is definitly a tsMuxer issue so thread should be mooved accordingly. It will affect, however, most solutions as they all seem to rely on it (that's what happen when you put all you eggs in the same basket).
For the torrent thing, i understand this might go against forum rules though it always make me smile to have such rules in an environment where it's obious purpose it to duplicate discs otherwise why giving so much trouble (please don't mention the scientific challenge). I was just trying to pull some heads out of the sand. Sorry for that. Delete my post if it go against some rules.
I don't think Win7RC7100 is a so unusual install, actually, this is probably the OS most power user enthusiasts have been experiencing during 2009.
March is when the trial will be over. I plan to get my RTM version before that, probably next month.
Thanxs again everyone, especially Deank for helping me pointing out where the problem was lying. Meanwhile i have a couple of plans to try (like slowing down my machine a bit) etc.
:thanks:
GaPony
10th November 2009, 16:35
Forgive me if I'm skeptical about the possibility that your machine is too fast... I'm sure if that were the case, there would be headlines in the New York Times, not to mention floods of "Intel creates monster" blogs all over the internet. That just isn't happening.
Perhaps a more conventional approach to problem solving may work better for you, since you live on a round world. :)
neuron2
10th November 2009, 16:46
@PhilippeB
Please stop talking about torrent downloads (rule 6) and musing about the rules (rule 17), else strikes can follow. Thank you.
PhilippeB
15th November 2009, 16:46
Everybody, just wanted to give some positive updates.
I went back to the drawing board and found some compatibility issues between my RAM and my motherboard. Problems that i though were fixed due to previous successfull and intensive tests with memtest86+, but it look like it came back.
After tweaking manually (and with a few tips from Mushkin) i was successfull.
Now tsMuxer doesn't seems to be a problem anymore. Though i still don't understand why this was affecting only this program, i had much heavier environments like visual studio + platform builder + CE6 working like a charm. Oh well..
The important thing is now tsMuxer seems to work fine.
:thanks:
jdobbs
15th November 2009, 17:36
Everybody, just wanted to give some positive updates.
I went back to the drawing board and found some compatibility issues between my RAM and my motherboard. Problems that i though were fixed due to previous successfull and intensive tests with memtest86+, but it look like it came back.
After tweaking manually (and with a few tips from Mushkin) i was successfull.
Now tsMuxer doesn't seems to be a problem anymore. Though i still don't understand why this was affecting only this program, i had much heavier environments like visual studio + platform builder + CE6 working like a charm. Oh well..
The important thing is now tsMuxer seems to work fine.
:thanks:I'm guessing TSMUXER must have been requiring more memory than the other software typically does... you see that a lot in muxing and encoding.
setarip_old
15th November 2009, 19:32
@PhilippeB
Congratulations on apparently solving your "unique" problem.
In light of this, it's hard to resist re-posting things from very much earlier in this thread (that you initially resisted), such as:Check for overheating (and gunk/dust bunnies) and/or less than perfect connections and seating of cards...and I'm sure that with your 20 years' experience, you are very familiar with both "Murphy's Law" and the phrase, "Better safe than sorry".
Again, congratulations ;>}
GaPony
16th November 2009, 06:01
Its amazing what we find when we start looking at our own systems...
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.