PurpleMan
24th October 2003, 22:19
Hello.
I wrote this post in a Q&A format to be more clear, understandable, and easy to read. I hope it satisfy its readers.
-----
1) What are we trying to accomplish?
We are trying to accomplish an easy, efficient, and foolproof way of backing up any retail DVD9 to a a DVD5 size that we can later on burn on a DVD-R/W or a DVD+R/W.
2) What's wrong with the "One-Click" solutions like DVD-Shrink?
The "One-Click" solutions like DVD-Shrink are transcoders, the quality is simply unacceptable and defeats the purpose of having a movie on DVD, which is quality.
3) We still have a soltuion called "The Big Three". Why not just use that?
Let me start by saying that "The Big Three" way of backing up a DVD9 into a DVD5 is currently by far the BEST way we have at our disposal. However, It is quite far from being perfect, and has many unresolved issues. As of today, "The Big Three" is far from supporting all titles out there. It can't do Seamless Branching, Complex Multi-Angle, Botton-Over-Video, and not to mention Infinifilm. It's also fair to say that even in titles that does not fit the categories I've just mentioned there are still many problems with the process. To sum it up bluntly, "The Big Three" is a long procedure, and it leaves ALOT of room for mistakes, improperly reauthored streams, inability to 'fast search' within a playing title, and unknown amount of incompatibilities of different sorts from many users trying to figure out their mistakes, if at all.
4) I kind of recall that when DVDR just started out, there was a way of just encoding the MPEG2 file, and remuxing it back to the original authored DVD. Why don't we use that?
That solution is perfect in concept, but fails misserably when being performed. In order to mux a MPEG2 file back to the original authored DVD it has to match the original. This means that it has to be of the exact same GOP structure, timecodes, locations of I,B,P frames, and FRAME TYPES (progressive/interlaced).
5) Why does it have to match the original? What difference does it make?
The IFO file of the original authored DVD contains many pinpoints and properties of the original M2V file. These pinpoints and properties indicate and affect the syncing of the audio, subtitles, chapters, scenes, and many other variables especially in Infinifilm and other menu-driven features.
6) Okay, let's do that! What's the problem?
ReMPEG2 is the only encoder that could make this work, as it used to read the original M2V file and encode a new file at a lower bitrate that matched the source in every aspect. The problem with that was the poor (and unacceptable) quality.
7) TMPGEnc and CCE both support the following of an inputted I frame sequences and GOP strcutures, What's the problem with that?
Let's start with the easiest one to explain. CCE just claims to follow an inputted order, but it completely ignores the locations of the I frames you input, someone from this forum awhile back said "as if it knows better". As for TMPGEnc, it is true - YES! it can follow a specific GOP structure and it does it correctly too!
8) Why don't we use TMPGEnc then?
That's what I asked myself too. At first, I thought of the obvious - Quality isn't enough. People who choose not to transcode because they want quality won't settle for anything less than CCE, right? WRONG! TMPGEnc 2-PASS VBR at *HIGHEST* (NOT normal or very-high like people have tested before) motion search accuracy is equivalent in both time and quality to a 9-PASS-VBR CCE encode. I tested this thoroughly on 3 titles, one of which being "The Matrix" which took in both cases roughly 21 hours to encode (P4 2.53GHz, 512MB), and both resulted in a perfect encode. I have many screenshots of comparisions between the two, but I will not post them as of now because they are irrelelvent to the discussion I'm trying to invoke. You'll just have to take my word for it. So the reason we're not using TMPGEnc is not the quality. The real reason is that our assumption was ultimately wrong.
9) And what assumption would that be?
Since I can remember myself, we always assumed that the way to use CCE/TMPG with IFOEDIT will be making CCE follow a GOP Structure, and if we achieve that, we can backup any dvd, easily and fast. That assumption while looks geniusly correct (and impossible) is also ultimately wrong in 99% of titles. In order to remux a stream back using IfoEdit it has to meet 2 requirements. The first requirement is the file following the same GOP structure, which was what we always knew. The second requirement is the file having the EXACT same number of hard-coded frames and in the EXACT same encoding method (progressive/interlaced - 23.976 pulled-down/29.970 interlaced). Even if we could make CCE work like TMPG can work, neither of the encoders can meet the second demand.
10) What are you talking about? You can choose the way the encoder works, AND the frame-rate.
Yes, but that's working under the assumption that your ENTIRE stream is the same. Either 100% progressive or 100% interlaced. What would you do if you have a PGC that has first 200 frames (studio logo maybe?) encoded at 29.970 interlaced, and the rest of the stream as 23.976 progressive pulled down? Even if you could make CCE/TMPG encode with the correct GOP structure, you can't make it encode first 200 frames as interlaced, and the rest as 23.976 pulled-down. That can be easily work-arouned'ed for this specific case, but what happens what you have 5 frames in the middle of the stream? or a hybrid source? This approach is virtually impossible, and the wrong way to go.
11) Okay, so we obviously can't use remuxing as well. What is the way to go?
Who said remuxing isn't the way to go? it IS! just not the way it was grasped by people until now. We always assumed that we have to make an M2V file that will match the original. That assumption is again, false. We need to have the IFO adjusted to match the new M2V file, and not vice-versa. You have to analyze the new M2V and compensate for the differences. this is the ONLY way of to make a perfect DVD9->DVD5 conversion that will ALWAYS work, be 100% compatible, fast and efficient, and as a bonus, won't even require the sacrifice of alot of free space for the process.
12) Don't we need the official DVD-Specs to be able to compensate for the differences between the M2V files in the IFO?
No. This is a common error. As of today (to the best of my knowledge or what I had researched), we have the knowledge to change EVERY SINGLE THING within an IFO file. We are just not sure of what needs to be changed, and how to 'translate' the analyzed M2V file into data that needs to be placed in the IFO. Once we accomplish that a simple front-end program which can be done by Eyes`Only (already talked to him) will be able to give you a complete solution for DVD backup, while maintaining the highest quality and highest compatibility, with minimal space requirements, minimal error margins, and most importantly, minimal effort.
----
Thank you for your time. Any comments, insights, ideas, innovations, and criticism will be greatly appreciated and welcomed as long as it's in a civil and productive way.
PurpleMan.
I wrote this post in a Q&A format to be more clear, understandable, and easy to read. I hope it satisfy its readers.
-----
1) What are we trying to accomplish?
We are trying to accomplish an easy, efficient, and foolproof way of backing up any retail DVD9 to a a DVD5 size that we can later on burn on a DVD-R/W or a DVD+R/W.
2) What's wrong with the "One-Click" solutions like DVD-Shrink?
The "One-Click" solutions like DVD-Shrink are transcoders, the quality is simply unacceptable and defeats the purpose of having a movie on DVD, which is quality.
3) We still have a soltuion called "The Big Three". Why not just use that?
Let me start by saying that "The Big Three" way of backing up a DVD9 into a DVD5 is currently by far the BEST way we have at our disposal. However, It is quite far from being perfect, and has many unresolved issues. As of today, "The Big Three" is far from supporting all titles out there. It can't do Seamless Branching, Complex Multi-Angle, Botton-Over-Video, and not to mention Infinifilm. It's also fair to say that even in titles that does not fit the categories I've just mentioned there are still many problems with the process. To sum it up bluntly, "The Big Three" is a long procedure, and it leaves ALOT of room for mistakes, improperly reauthored streams, inability to 'fast search' within a playing title, and unknown amount of incompatibilities of different sorts from many users trying to figure out their mistakes, if at all.
4) I kind of recall that when DVDR just started out, there was a way of just encoding the MPEG2 file, and remuxing it back to the original authored DVD. Why don't we use that?
That solution is perfect in concept, but fails misserably when being performed. In order to mux a MPEG2 file back to the original authored DVD it has to match the original. This means that it has to be of the exact same GOP structure, timecodes, locations of I,B,P frames, and FRAME TYPES (progressive/interlaced).
5) Why does it have to match the original? What difference does it make?
The IFO file of the original authored DVD contains many pinpoints and properties of the original M2V file. These pinpoints and properties indicate and affect the syncing of the audio, subtitles, chapters, scenes, and many other variables especially in Infinifilm and other menu-driven features.
6) Okay, let's do that! What's the problem?
ReMPEG2 is the only encoder that could make this work, as it used to read the original M2V file and encode a new file at a lower bitrate that matched the source in every aspect. The problem with that was the poor (and unacceptable) quality.
7) TMPGEnc and CCE both support the following of an inputted I frame sequences and GOP strcutures, What's the problem with that?
Let's start with the easiest one to explain. CCE just claims to follow an inputted order, but it completely ignores the locations of the I frames you input, someone from this forum awhile back said "as if it knows better". As for TMPGEnc, it is true - YES! it can follow a specific GOP structure and it does it correctly too!
8) Why don't we use TMPGEnc then?
That's what I asked myself too. At first, I thought of the obvious - Quality isn't enough. People who choose not to transcode because they want quality won't settle for anything less than CCE, right? WRONG! TMPGEnc 2-PASS VBR at *HIGHEST* (NOT normal or very-high like people have tested before) motion search accuracy is equivalent in both time and quality to a 9-PASS-VBR CCE encode. I tested this thoroughly on 3 titles, one of which being "The Matrix" which took in both cases roughly 21 hours to encode (P4 2.53GHz, 512MB), and both resulted in a perfect encode. I have many screenshots of comparisions between the two, but I will not post them as of now because they are irrelelvent to the discussion I'm trying to invoke. You'll just have to take my word for it. So the reason we're not using TMPGEnc is not the quality. The real reason is that our assumption was ultimately wrong.
9) And what assumption would that be?
Since I can remember myself, we always assumed that the way to use CCE/TMPG with IFOEDIT will be making CCE follow a GOP Structure, and if we achieve that, we can backup any dvd, easily and fast. That assumption while looks geniusly correct (and impossible) is also ultimately wrong in 99% of titles. In order to remux a stream back using IfoEdit it has to meet 2 requirements. The first requirement is the file following the same GOP structure, which was what we always knew. The second requirement is the file having the EXACT same number of hard-coded frames and in the EXACT same encoding method (progressive/interlaced - 23.976 pulled-down/29.970 interlaced). Even if we could make CCE work like TMPG can work, neither of the encoders can meet the second demand.
10) What are you talking about? You can choose the way the encoder works, AND the frame-rate.
Yes, but that's working under the assumption that your ENTIRE stream is the same. Either 100% progressive or 100% interlaced. What would you do if you have a PGC that has first 200 frames (studio logo maybe?) encoded at 29.970 interlaced, and the rest of the stream as 23.976 progressive pulled down? Even if you could make CCE/TMPG encode with the correct GOP structure, you can't make it encode first 200 frames as interlaced, and the rest as 23.976 pulled-down. That can be easily work-arouned'ed for this specific case, but what happens what you have 5 frames in the middle of the stream? or a hybrid source? This approach is virtually impossible, and the wrong way to go.
11) Okay, so we obviously can't use remuxing as well. What is the way to go?
Who said remuxing isn't the way to go? it IS! just not the way it was grasped by people until now. We always assumed that we have to make an M2V file that will match the original. That assumption is again, false. We need to have the IFO adjusted to match the new M2V file, and not vice-versa. You have to analyze the new M2V and compensate for the differences. this is the ONLY way of to make a perfect DVD9->DVD5 conversion that will ALWAYS work, be 100% compatible, fast and efficient, and as a bonus, won't even require the sacrifice of alot of free space for the process.
12) Don't we need the official DVD-Specs to be able to compensate for the differences between the M2V files in the IFO?
No. This is a common error. As of today (to the best of my knowledge or what I had researched), we have the knowledge to change EVERY SINGLE THING within an IFO file. We are just not sure of what needs to be changed, and how to 'translate' the analyzed M2V file into data that needs to be placed in the IFO. Once we accomplish that a simple front-end program which can be done by Eyes`Only (already talked to him) will be able to give you a complete solution for DVD backup, while maintaining the highest quality and highest compatibility, with minimal space requirements, minimal error margins, and most importantly, minimal effort.
----
Thank you for your time. Any comments, insights, ideas, innovations, and criticism will be greatly appreciated and welcomed as long as it's in a civil and productive way.
PurpleMan.