This forum is for users to exchange information and discuss with other users about a TMPGEnc product.
In case you need official support, please contact TMPG Inc.
Pegasys Products BBS [ Sorted by thread creation date ]
Admin my apologies once again for a double post, I JUST don't understand WHY this is happening, and I only press submit ONCE. I have set a password on some posts in the event that I noticed it happen again and yet when I enter the password to either edit a typo , or delete an unintended double post, even after i enter the password, the page just loops back to the enter password screen, please check this as I believ ther may be a problem there. Thanks
Stop refreshing the page after you have posted and you won't double post. To refresh the page click the 'View article' link at the bottom and no one can edit their posts not just you.
I'm converting an avi file into mpeg2 and the final mpeg file is just a little to big (5 GB) to burn to a dvd.
How can I set a limit on the file size?
If I use the project wizard then I can set 'Make file size xx % of disk capacity' but since I have made my own template I'm not using the wizard and I don't see this possibility anywhere in the main window.
Thank you for all your comments and requests. This is just to let you know that we are listening to what you are suggesting and we will try and inprove the product in accordance with your suggestions.
Yesterday we released an updated version, which will have changed the following things:
TMPGEnc DVD Author 1.0.10 (1.0.10.36)
07Added: The Create menu functions include "Motion menu".
07Improved: Renewed version of the "Sofdec" MPEG decoder.
07Changed: A Multi_PGC_Title that some authoring software creates can also be read when reading a DVD-Video.
07Added: An MPEG file can be used as background in the menu.
07Added: Audio can be played in the Track preview window, the Edit clip window, and the Thumbnail picture selection window. (AC3 audio cannot be played).
07Improved: Better quality when performing audio sampling rate conversion, and higher processing speed.
07Added: When outputting a DVD folder it is not only possible to save it in a child folder named "Volume xxx" but also in a folder named "Volume xxx (project name)". (Selectable in Environmental settings)
07Added: Now supports using DVD video recording standard (VRO) format, recorded in VR mode on a DVD-RAM recorder, etc. as input. In order to use this function, it is necessary to have a PC system that includes drive, device driver, etc. that corresponds to the object media. If the file cannot be copied in Windows, you cannot use this function. Whether or not your system will be able to read such files is determined by many different factors, and we are therefore unfortunately not able to answer any questions how to solve this.
The VRO files written below are different from the DVD-Video standard and cannot be used.
*VRO files with changing video bitrate such as Advanced VRO.
*Files with other resolutions than 720x480, 704x480, 352x480, or 352x240.
*Files where the audio format has not been standardized to LinearPCM, MPEG-1 Audio Layer2, or Dolby Digital AC-3.
07Changed: The project file format has been changed. Project files created in this version cannot be used in previous versions.
07Changed: Various minor things.
07Updated the Help file.
Yeah, very nice. But without a chance to try the new features without restoring an old Windows-Image to reset the Test-Time (30 Days).
Nothing against the 30 Days-Rule, but if you have new features, you should give the Users a chance to try them without "hacking" windows.
Great to hear of improvements. How do we update our trial versions?
>Thank you for all your comments and requests. This is just to let you know that we are listening to what you are suggesting and we will try and inprove the product in accordance with your suggestions.
>
>Yesterday we released an updated version, which will have changed the following things:
>
>TMPGEnc DVD Author 1.0.10 (1.0.10.36)
>
>07Added: The Create menu functions include "Motion menu".
>
>07Improved: Renewed version of the "Sofdec" MPEG decoder.
>
>07Changed: A Multi_PGC_Title that some authoring software creates can also be read when reading a DVD-Video.
>
>07Added: An MPEG file can be used as background in the menu.
>
>07Added: Audio can be played in the Track preview window, the Edit clip window, and the Thumbnail picture selection window. (AC3 audio cannot be played).
>
>07Improved: Better quality when performing audio sampling rate conversion, and higher processing speed.
>
>07Added: When outputting a DVD folder it is not only possible to save it in a child folder named "Volume xxx" but also in a folder named "Volume xxx (project name)". (Selectable in Environmental settings)
>
>07Added: Now supports using DVD video recording standard (VRO) format, recorded in VR mode on a DVD-RAM recorder, etc. as input. In order to use this function, it is necessary to have a PC system that includes drive, device driver, etc. that corresponds to the object media. If the file cannot be copied in Windows, you cannot use this function. Whether or not your system will be able to read such files is determined by many different factors, and we are therefore unfortunately not able to answer any questions how to solve this.
>The VRO files written below are different from the DVD-Video standard and cannot be used.
>
>*VRO files with changing video bitrate such as Advanced VRO.
>*Files with other resolutions than 720x480, 704x480, 352x480, or 352x240.
>*Files where the audio format has not been standardized to LinearPCM, MPEG-1 Audio Layer2, or Dolby Digital AC-3.
>
>07Changed: The project file format has been changed. Project files created in this version cannot be used in previous versions.
>
>07Changed: Various minor things.
>07Updated the Help file.
Is it right that it's not enough to rely on the VideoCD template, or on the wizard, to convert DV-AVI to VideoCD-MPEG?
If the source video is 720x480, the source aspect ratio is in fact 704x480. In order to convert it properly to 352x240 and preserve the aspect ratio, the source frame must be clipped by 8 pixels from the left, and by 8 pixels from the right: 720-8-8=704.
It's the same in PAL conversions, from 720x576 to 352x288.
Those 8 pixels in the left and in the right wouldn't show on the TV, anyway. It's more important to have a video in the right aspect ratio; or, it shouldn't be converted to a 4:3 format.
Shouldn't the default settings do this clipping, if the video is 720x480, but the source ratio is 4:3 <-> 704x408? Ditto about PAL/576.
That's right. To convert 720 -> 352 you have to clip 16 Pixels. An other Way is to resize 720x576 -> 352x280 without cropping, letterboxing to 352x288.
In NTSC-World, you can do it this Way: Resize to 352x236 without cropping, letterbox to 352x240. But this isn't realy good, because of the strange Resizing. The best Way is to clip always to 704.
This is another suggestion for Mr. Hori - that 720x480/720x576 video should be clipped by 8+8 pixels by default, when converted to any format that maintains the same pixel aspect ratio, and the frame fills a 4:3 rectangle (such as VideoCD, or 640x480, or 320x240, etc.)
I've seen a couple of VideoCDs, converted from VHS or TV capture, that have black vertical margins and an incorrect pixel aspect ratio (i.e. people appear "too tall".) I believe the users of TMPGEnc who did the conversion didn't know that they were doing it wrong.
I don't know if my suggestion is better handled in the program, or in a template.
That's incorrect. Well for your information the authors of TMPG have already compensated for this.
TMPG automatically adjusts the aspect ratio to acount for the difference in pixels.
You will notice that when resizing from 720x480 to 720x240 that image is not only compressed by 8 pixels either side vertically, but TMPG also compresses the image horizontally by the right amount of pixels regarding the aspect ratio to compensate and just fills the rest in with black.
If you clip 8 pixels either side your image will infact have the wrong aspect ratio or if you resize the image vertically so it's a few pixels short.
If you don't believe it just play the original in media player and put your thumbnail on the top or bottom edge of the image then without removing your thumb play your resized clip. You will noticed the image is also compressed a few pixels horizontally to compensate and maintain the correct aspect ratio.
>You will notice that when resizing from 720x480 to 720x240 that image is not >only compressed by 8 pixels either side vertically
Sorry this should read: You will notice that when resizing from 720x480 to 352x240 that image is not only compressed by 8 pixels either side vertically
>That's incorrect. Well for your information the authors of TMPG have already compensated for this.
>TMPG automatically adjusts the aspect ratio to acount for the difference in pixels.
I am glad to know this, although it doesn't happen in my version of TMPGEnc (2.59.47.155). I am sure about it, because I tested it with a 720x480 video that has 8-pixel-wide black margins on the left and on the right. If I don't clip anything, those margins appear (albeit narrower) in the encoded video (they shouldn't).
Maybe a newer version of TMPGEnc does it properly. When I'll have time, I will download the latest version and test it.
Huh, what Ashy said is right, but, there's a big reason, NOT to use this Resizing-Feature in TMPGEnc (and other Programs): It is called the Nyquist-Effekt. It's a theorem about Resizing and it is exactly what i meant with "Strange Resizing".
I must appologize, but my english is not good enough to give you an Explanation about the Nyquist-Effekt, but it exist and can be noticed. It results in unsharp mixing of Pixels, and it does not happen, if you do the Cropping to 704.
704 / 2 = 352
480 / 2 = 240
If you use the Resizing-Feature for the 720 Format, the division Factor is not 2, it is a foating-Point Opperation.
Sorry, that's al i can "stutter" about that in english. :(
About Aspect Ratios: 720 and 704 do have exactly the same ASR, that's because the 720 Format do use an Motion Area of 704.
>If you clip 8 pixels either side your image will infact have the wrong aspect ratio or if you resize the image vertically so it's a few pixels short.
Say I have to convert from 720x480 to 352x240.
The 720x480 source has 704x480 of its pixels to fill in a 4:3 rectangle (this is why the "source aspect ratio" is called "704x480 4:3"). Therefore, the entire source frame is actually wider: it's not 4:3 = 1.3333..., but it's (4:3)*(720/704) = (4:3)*(45/44) = 1.3636...
For example, if you play a 720x480 video in full screen, you will see thin, horizontal black bars at the top and at the bottom. If you play a 352x240 video or a 704x480 video in full screen, that occupies indeed the entire screen. The video looks higher, but also wider, by the proper amount necessary to preserve the aspect ratio.
Therefore, if you clip 8 pixels on the left and 8 on the right, you will get a narrower video, which occupies a full 4:3 rectangle, and preserves the correct aspect ratio at the same time.
Ditto with 720x576 --> 704x576 / 352x288 in PAL/SECAM countries.
The "No motion search for still picture part by half pixel" option is on by default in the VideoCD templates. However, I noticed in other MPEG encoders that they enable motion search by half pixel by default, and recommend using it because they claim it's better. In fact, the MPEG committe included half motion in the standard in order to increase quality.
My very subjective impression with TMPGEnc is that half-pixel motion search gives slightly better results, either if it is a movie shot with a camcorder in the hand (which has fast and slow motion, but almost no stills), or on a tripod (which has also stills, at least in parts of the image).
Am I right, or is the template right, or is it simply the fact that "you can't tell"?
It's true that I didn't have frames with "complete stills", only "still background, moving subject". But even in this case, half-pixel motion search was better, so I had to override the TMPGEnc template.
Half PEL search is good if you have good Source (sharp, clear, less Noise). You should aktivate it.
But if you have Captures from older Tapes with flickering Object-Borders, it's better to deaktivate Half PEL Search. That's because the encoder gives the Borders too much Bitrate and too less on now motion Parts into a picture which results in strange Effekts.
Thanks, Kika, for the answer. Yes, my source is Digital Video, which has some noise indeed, but it's very little. It's good to know that this kind of video is better compressed with HalfPel search enabled.
As a suggestion: I think that many people convert their digital videos (or other kinds of high-quality video) to MPEG, and I doubt that they know HalfPel search is better the source is DV; probably, they will just use the defaults. It would be a good idea to mention this in the "tooltip" message associated to the HalfPel checkbox setting.
I am using TMPGEnc to convert DV-AVI to VideoCD. On DV-AVI, the YUV data is already in the CCIR601 format, so there is no need to convert it again (in the box MPEG Settings/Quantize Matrix/Special Settings/Output YUV...). I am checking on this box, assuming that the YUV data remains unaltered. I assume that every conversion to CCIR601 loses some data (Y is squeezed from 0-255 to 8-235).
My observation is exactly the opposite: the "conversion to CCIR601" preserves the data, while the "conversion to YCbCr" alters it (maybe Y is expanded from 8-235 to 0-255).
I noticed this by repeatedly compressing a MPEG file. If I use "output as CCIR601" repeatedly, the pixels' intensity is preserved. If I use "output as YCbCr" repeatedly, the intensity is expanded to "too much white" or "too much black".
Is this the right behavior? If yes, then the recommendation written in the yellow box that appears as a tooltip is wrong (and my first assumptions are also wrong). If not, then I think there's a bug in this conversion.
I am using TMPGEnc version 2.59.47.155. I am willing to upgrade to the latest version, if this problem is already solved.
I've used VirtualDub to strip the uncompressed sound out of an avi i've got. I then use tmpgenc to encode but every time I try the sound doesn't come out. It doesn't complain about the wav file i give it - the sound just doesn't come out of the resulting mpg. I keep trying just 300 frames to check but to no avail.
I'm pretty new to this and it's my first time so please help.
Have you checked the Wav file to see if it has sound?? If all else fails you can take the Wav file (If it has sound) and use a Totally seperate audio encoder to Encode it to Mpeg 1 layer 2 audio then use Tmpgenc"s "Simple Multiplex" in the Mpeg tools to Join the Mpeg audio to the Video...There are a Few Freeware Mpeg audio encoders like "Headac3he" and even "DB Power AMP" can do it....
I am very new to 'Encoding' video files. I have used the free version to encode an AVI file to MPEG1 no problems the first time, but the second time I tried to encode an AVI file to MPEG1 for VCD PAL, I get an error saying 'cannot open file or unsupported'. What do I need to do?
Because you sucessfully encoded an avi file doesn't mean you will always have the same success with every avi file, as Avi files are encoded by different means, you need to find out what the encoding of the source is, by using a program called GSpot or the like, then in TMPGEnc go to Options,Environmental Settings, VFAPI -plugins and raise the priority level of the codec decompressor to match the encoder that GSpot showed the original source to have been. The error message that you gave appears to be this problem (The VFAPI-plugin needs to be prioritized correctly or it won't recognise (unsupported) the source.
Because you sucessfully encoded an avi file doesn't mean you will always have the same success with every avi file, as Avi files are encoded by different means, you need to find out what the encoding of the source is, by using a program called GSpot or the like, then in TMPGEnc go to Options,Environmental Settings, VFAPI -plugins and raise the priority level of the codec decompressor to match the encoder that GSpot showed the original source to have been. The error message that you gave appears to be this problem (The VFAPI-plugin needs to be prioritized correctly or it won't recognise (unsupported) the source.
I'm converting an avi file into mpeg2 and the final mpeg file is just a little to big (5 GB) to burn to a dvd.
How can I set a limit on the file size?
If I use the project wizard then I can set 'Make file size xx % of disk capacity' but since I have made my own template I'm not using the wizard and I don't see this possibility anywhere in the main window.
If you use a "Bitrate Calculator" you can use to to figure out the Bitrate you would have to use for the length of the movie you are encodeing so it fits on a DVD..
I'm using cladDVD XP 1.32 which creates VOB, WAV and D2V files. My understanding is that TMPGenc ver 2.57 would be able to read the D2V file as the fie to use to encode along with the VOB files the WAV file of course would be audio.
First the D2V file doesn't appear as a valid file to use and when I try to use the D2V file to encode from the error cannot open or is unsupported pops up. Others I know use this same combination of software and have had no problems with it.
For Tmpgenc to accept D2V files the "DVD2AVI.vfp" Plugin has to be installed, you install it by Downloading DVD2AVI and takeing the "DVD2AVI.VFP" file from the DVD2AVI folder and Copy and Pasteing it into the Tmpgenc folder...But it is Best NOT to use the D2V files created By CladDVD XP or DVD Decrypter or Smartripper and use DVD2AVI to make the D2V file, Cuz DVD2AVI has options that effect the Quality and the way the Image looks which your DVD Ripper doesn"t have, Plus the D2V files from DVD2AVI are more compatible.....
Admin I tried to delete the second post that is timed 16:40 but I could not, I am not sure how this happened I must have done something wrong, please delete the post with the time 16:40 ( The one about asking King John) for me, thank you, and again my apologies.
What exactly is JUNK frames? And if it effects TMPGEnc, and causes it to crash midway or at some point of the encoding process, how can one solve the problem?
I guess there can be a Few things that can be considered Junk frames,But most of it has to do with Files that have been captured and the Only Kind of frames that can cause Tmpgenc to crash are Corrupted frames which are Very common with Downloaded files...
I think it's something different, based on what I saw in Gspot, there is a reference to JUNK as code under "comments and metadata" section ,also shows JUNK as (ASCII in Junk Chunk)under the RIFF info field. So I think it's some type of encoding done to the source, I also see that vdub was was used.