TyTool 9r14 - Extraction/Frame Accurate Editing/DVD output...

[jdiner]

Alright. The rules in this thread are the same as the last one for my tools. A great many things have been updated recently. And there are some pretty sweet features coming in the near future. But as always it is best to start with a charter for this thread.

Just like before these are rules for this thread, not the forum. If you want to discuss things deemed off limits here make your own threads and set your own rules. But if you decide to participate here then please follow the guidelines.

So the rules for this thread are:

1- NO FLAMES AND NO ARGUMENTS... I am through trying to be nice on this as it just plain does not work. I will without reservation delete anything that shows up here that could be considered either of the above. Enough is enough.

2- It has become clear that we have 2 distinct camps with zealots in both. Fine. Use my stuff. Use Olaf's. I couldn't care less. Many of us got dragged into a war we didn't know we were supposed to be involved in... So a new rule. We discuss ONLY my own tools here... Leave the rest in their own threads! This is not intended to be an attack but rather to stop them. You don't like me. Fine. You don't like my tools fine. You don't like those that use them. You're an ***** but fine for hating people you have never ever met so just go somewhere else.

3- NO ADVERTISING FOR OTHER TOOLS. Again this thread is again about Vsplit/TyTool. If you have something cool to use in place of or even with them the take it to a different thread. Any post by anyone about "you really should use X instead..." is gone the moment I or some of other mods see it.

This is still an open forum. Create your own thread and have at it. But such posts are entirely unwelcome here.

4- Feel free to discuss various OS/wishes/desires/etc.... At some point we should support as much as is possible.

5- Feel free to ask for features but be aware that I am making no promises except to work on things in general... I mean it. Ask. But don't hound me or anyone else, that accomplishes nothing. If you think of something that would be cool let me know. I will add it to the list.

6- I suppose I should say it... I reserve the right to disappear at any time. Just like you do. When life interferes hobbies get put on hold. Having said that it will be obvious when you look at the new toolset that I have been putting in a great deal of time on it. Hope that it helps every do what they want to with their Tivos...

7- Keep DVDLab, tmpgenc et all to a dull roar in here please. It might be better say that we are now 3 camps. TyTool, TyStudio, and TyTool with the output being used elsewhere. I don't mind the occasional this works with DVDLab/Tmpgenc etc... in reference to a problem someone asks about. But in the last while it has felt like we had dropped to advertising again. Please don't do that. There are a number of very good DVDLab threads here on the forum to do that kind of thing etc...


An important note!

Several of these programs require the cygwin1.dll to run. Some of the tools in the TyTool release, mpeg2enc and dvdauthor most notably, were compiled with the cygwin cross compiler. To run these require the presence of the cygwin1,.dll file. This file is huge and seems to get larger all of the time. There is no need to download a new copy of this file everytime. While it does change it is not that frequent. So please download the zip for it from here in this post or else grab it from the homepage: www.cygwin.com (http://www.cygwin.com)

Again, if you try to use the Frame Accurate Editing or DVD features of TyTool this dll is required. If you see a major popup window when trying you are missing the dll. Please unpack the DLL into the same directory as the rest of the TyTool files and executables.

--jdiner

[jdiner]

TyTool 9r14 with DVD Support. The attachment has the new versions of the tooset in it. All DVD extras and tserver versions are found within it. VSplit has not been updated to match this release. Although an update for it is planned in the near future.

Version 9 is a major upgrade from the earlier 8 series of TyTool. It adds Frame/Field Accurate Editing (FAE) to the mix.

Please check the included docs for information about it. The release notes for 9r1 up to the current as each contains detailed informtion about the FAE editing process and other changes.

Highlights of the Fixes and Features in this Release:

42- Added the Delete code into TyTool for cleaning up an existing DVD filesets.

164- Fix the start & end cut points to check to make sure the end is "after" the start. Just a simple fix to try and keep the editing working more smoothly.

206- Make the attach vob use a new dialog with a listbox, so we can have more than 1 at a time.

235- Force a check to make sure that none of the chapters are within a section where a cut has occured. Again just try to make editing a bit more smoothly.

281- Add a help popup to GopEditor for what keys do what. Just trying to make it easier for new users.

282- Added an about with a copyright notice to TyTool. An attempt to stop people from selling it on EBay etc...

283- Add a simple help page to TyTool. (Getting started info.) Not a network-based FAQ but something local.

285- Check the font setting in the template loading code. Some where having problems. Could not reduplicate any errors.

287- Fix the "missing" entries in NowShowing. We need to get good data so that people sorting and using a way out of date NowShowing.tcl will not get crashes etc...

298- Put in a check to see if there is something in the DVD output directory. Warn/erase if there is.

308- Make a simple network test and let's see if we can drive 2 sockets faster than one... Amazingly enough no. Just trying to use the networking with no extraction and we get exactly 1/2 of full speed on each one.

316- Add an overlap detector and don't allow it. Yet another editing check to make sure that 2 cuts can't overlap.

317- Added a jpeg decoder. You can now use BMPs or JPGs as the background image for the menu. Sadly the it adds 30k to the size of TyTool but it was something that many wanted so there you go.

319- Tested the Image quality of the JPGs. Looks great. Well probably good enough for everyone but FredThompson. :)

324- Fix the rendering of the GopEditor when the size is really really off. Forgot to put a few things into the resize code. So they never moved.

325- Tried to fix the "locked" dir when TyTool is making an IFO. Couldn't find anything that was being left locked. So for now considering it fixed...

330- Added the multiple attach vob feature to the menu dialog. Changed the old process. You now get a new window where you can add, remove, and order the vobs.

331- Finish adding the JPEG support to loading of menu images. Oooppps. Major memory leak going on there. Fixed and running smoothly now.

335- Added the Free Space/Total Space Used display to TyTool for the local dir in use to the main TyTool interface window.

336- Add a "total size" for the VOB-list in the picker for Making an IFO. Shows how big the selected VOB files are to be able to more easily guage how much will fit. For those using dvdshrink or rejig or whatever you are on your own to figure out what boundaries are best for you.

337- Threaded the download of the NowShowing data so that it does not lock the main TyTool GUI any longer.

338- Put in an "only for so long" wait in the tserver start code. This way it will time out and not lock forever waiting for the telnet prompt...

345- Fixed the label on the call for making the DVD. It said VOB-Mux.

346- Fixed the "multiple VOBs" chaptering issues. You now get a completely seperate chapter list "-c" statment for each VOB in the final output.

347- Added the "a DVD exists here" MessageBox to the menu generation code. You can now stop the process at that point or delete and just keep right on going.

349- Fix the bytes vs. kbytes issue in the NowShowing download report. This was just a bad label but it has still been fixed.

350- Put a text element on the TyTool GUI for the free drive space. Used to be a menu option, but now it is on the GUI all the time.

357- Fix the cleanup delete code to only delete certain files not wildcard everything "just in case". Really did not want to wipe out files that were wanted.


From the TyTool9r13 a-c releases:

The ability to start and stop the server from within TyTool. With better support for setting the prompt within TyTool.

I have not yet gotten around to looking at the currently bad TyStreams from a few users. That was next on the list but I wanted to get these new fixes released before it went on any longer.

--jdiner

[jdiner]

These aren't here yet. Just a place hold for future releases.

--jdiner

[FredThompson]

sez it all

319 - phfbfbfbfhththththtttt!!!!

[jdiner]

One thought as people get ready to re-download things....

Most of the settings you make in TyTool that get kept are in the TyTool.ini file. If you keep this file from installation to installation rather than over-writing it you DO NOT have to keep reseting your settings each time.

If you install into the same directory then you have to manually have a copy elsewhere. If you put it into a new directory each time, i.e. one that reflects the version number, then just copy the file around.

TyTool is smart enough to fill in any missing config options and they will be present after the first run of the new version with whatever new settings you have selected.

--jdiner

[bluedog68]

I really like the Extra VOB feature. This makes the "no menu" option unnecessary; for me at least. I did find that if there is a ";" in the VOB title, the IFO creation step will not include that item. I don't know if other special characters have that effect. Obviously the work around is quite simple.

Thanks for all the hard work!!!

[jdiner]

I really like the Extra VOB feature. This makes the "no menu" option unnecessary; for me at least. I did find that if there is a ";" in the VOB title, the IFO creation step will not include that item. I don't know if other special characters have that effect. Obviously the work around is quite simple.
What part are you considering the VOB title? The ; character is no supposed to be a legal file name character. Oh man. It was a bit to late obviously is it the ":" character that should be used as the seperator and I used ";". I will have to fix that.

--jdiner

[jdiner]

Alright that is fixed. I will wait on the release to see what else bubbles to the surface before making the next release.

--jdiner

[bmm64]

I've only tried 9r13 and 9r14, but in both I get the dreaded

"Temporal References in GOP #0 are out of sequence"

error when importing into DVDMaestro. If I use 8r4 to download the same show, it'll work every time just fine.

Is this a known thing in 9 and I should just continue to use release 8???

tytool.ini was copied from release 8
ADDR:192.168.2.11
LOCALIP:192.168.2.51
LDIR:F:\tivo\ToProcess
DVDDIR:J:\VOUT
OUTDIR:F:\tivo\ToProcess\
MODE:VSPLIT
NET:NEW
MUX:STD
ULEAD:OFF
PATCHAUDIO:ON
GOPPOPUP:OFF
TRANSCODE:0

[OutlawPro]

With 9r14 I'm getting "We need to do some rebuilding here!" when I multiplex (using both the old and the new method). The resulting mpg crashes Nero Showtime (not at a cut) and has no video in WMP9 (has audio and doesn't crash, just get a black screen though). Went back to 9r13a and everything works fine again.

[jdiner]

I've only tried 9r13 and 9r14, but in both I get the dreaded

"Temporal References in GOP #0 are out of sequence"

error when importing into DVDMaestro. If I use 8r4 to download the same show, it'll work every time just fine.

Is this a known thing in 9 and I should just continue to use release 8???

tytool.ini was copied from release 8
ADDR:192.168.2.11
LOCALIP:192.168.2.51
LDIR:F:\tivo\ToProcess
DVDDIR:J:\VOUT
OUTDIR:F:\tivo\ToProcess\
MODE:VSPLIT
NET:NEW
MUX:STD
ULEAD:OFF
PATCHAUDIO:ON
GOPPOPUP:OFF
TRANSCODE:0

It isn't designed to work with Maestro. Never has been. If you had it working before you were just getting lucky. Continueing to use 8 might improve your chances and it might not.

Look at the menu creation stuff bundled into TyTool. It will always work without the need to mess around with changing resolutions and other things needed to get maestro to work.

--jdiner

[jdiner]

With 9r14 I'm getting "We need to do some rebuilding here!" when I multiplex (using both the old and the new method). The resulting mpg crashes Nero Showtime (not at a cut) and has no video in WMP9 (has audio and doesn't crash, just get a black screen though). Went back to 9r13a and everything works fine again.
Oh crap!

That can only happen in the new muxer code as that is where the check is but will happen in both MPG and VOB modes.

It was a half done change/fix/alteration. I thought I had pulled it out but in looking at the code again just now the answer is no it isn't fixed.

Can you cut a small segment that shows that error? part of why it was not done is that I could not find a way to make it happen here. It is just how data lines up...

If I can get one that shows it then I can hopefully get things working better with some of the other players out there.

--jdiner

[OutlawPro]

Sure, I'll try to get something for you to download tonight. Do you need something with just the errors in creating or something up to when it crashes Nero Showtime?

PS. You are right, only happens with the new muxer. I must have inadvertently selected it again when I thought I was picking the old way during my tests.

[OutlawPro]

PS. You are right, only happens with the new muxer. I must have inadvertently selected it again when I thought I was picking the old way during my tests.

Hmm...actually. If you start muxing the file with the new muxer, hit "Abort", and then try to mux with the old muxer, you get the same errors. The only way for the old muxer to work is to restart TyTool and use the old muxer first. Maybe there is some flag that is not getting reset when you abort, so it tries to use the new muxer the second time even if you select the old muxer?

[jdiner]

Hmm...actually. If you start muxing the file with the new muxer, hit "Abort", and then try to mux with the old muxer, you get the same errors. The only way for the old muxer to work is to restart TyTool and use the old muxer first. Maybe there is some flag that is not getting reset when you abort, so it tries to use the new muxer the second time even if you select the old muxer?
Quote probably. It was never designed to be used as it is in there now. It was supposed to be an option. My best guess is that I am not reseting the flag when you try to switch back. It should... I guess I just never got that far.

--jdiner

[edy]

I'm curious, will TyTool ever have the ability to play at normal speed with sound, even if just for [FG]AE cuts? There's a few shows that I've edited where there is a black screen but there is still some audio that is leading out, I'd be nice to be able to hear it or have some sort of VU meter that says 'there's still sound here'.

[malfunct]

I'm curious, will TyTool ever have the ability to play at normal speed with sound, even if just for [FG]AE cuts? There's a few shows that I've edited where there is a black screen but there is still some audio that is leading out, I'd be nice to be able to hear it or have some sort of VU meter that says 'there's still sound here'.

JDiner has mentioned this sort of thing but doesn't seem to have found a way that he likes to present the information. I'd say give it time, he wants some sort of feature like that for his personal use, so that makes it fairly likely it will happen.

[edy]

That'd be awesome!

I guess I'll just have to stay tuned and see what happens. Great program though!

[firemunky]

Just a question about subject option. Cool addition...would save me a few key strokes, but can't seem to get it to work.
my DTIVO has DNS name tivo and i have made an additional start file to get tyserver going.
When i tried from within tytool instead, the pop up says 'connecting to tivo....connected" but then times out saying it never got a telnet answer.

[deeder]

I have just installed a 120 Gig HD in my Direct TV SD-DVR40 and used Sleepers ISO. I am using a Linksys g wireless Hub for my home network, and on the back of the Tivo a Linksys USB200M. All the light on the hub seem to be showing that the TiVo is connected, and when I go to my PC I can ping the IP address that I put into Sleepers ISO.
I seem to ping OK.

But at the Hub it does not show it under the DHCP Clients Table.

Then trying the Tytools9r14 I get the message.
Trancode Selected Mode: 0
Ready...
Reading list from the server...
Clear Now Showing List...
Connecting to '192.168.1.112'
ERROR: Failed to Connect!


Could some one help please.

[malfunct]

Just a question about subject option. Cool addition...would save me a few key strokes, but can't seem to get it to work.
my DTIVO has DNS name tivo and i have made an additional start file to get tyserver going.
When i tried from within tytool instead, the pop up says 'connecting to tivo....connected" but then times out saying it never got a telnet answer.

What is your tivo prompt? It sounds like you haven't set your prompt (get at least 9r13c) and the procedure is stuck waiting for a default prompt that will never come.

[malfunct]

I have just installed a 120 Gig HD in my Direct TV SD-DVR40 and used Sleepers ISO. I am using a Linksys g wireless Hub for my home network, and on the back of the Tivo a Linksys USB200M. All the light on the hub seem to be showing that the TiVo is connected, and when I go to my PC I can ping the IP address that I put into Sleepers ISO.
I seem to ping OK.

But at the Hub it does not show it under the DHCP Clients Table.

Then trying the Tytools9r14 I get the message.
Trancode Selected Mode: 0
Ready...
Reading list from the server...
Clear Now Showing List...
Connecting to '192.168.1.112'
ERROR: Failed to Connect!


Could some one help please.


You are mixing together two issues here. First its fine that the tivo isn't on the DHCP table because it shouldn't be since you assigned it a static IP.

Second you need to execute tserver on the tivo in order for TyTool to have anything to connect to. Refer to the FAQ on tytool.com for information on starting tserver.

[malfunct]

That'd be awesome!

I guess I'll just have to stay tuned and see what happens. Great program though!

Just be patient (it looks like you are so no worries) because some things take a while. JDiner is a busy man and its amazing just how much he gets done on this hobby project in his free time.

[malfunct]

Just looking into making updates to the FAQ for 9r14 and was wondering why someone would want to use Attach vob and what it does. I think I know but just want better information.

[FredThompson]

Sometimes the entire "show" isn't in one vob. I've taken the intro from one recording and joined it to the body of another to make a complete segment. Wish it would support appending more than 1... This feeds 2 VOBs to the IFO creation process resulting in one com bined VOB.

[malfunct]

Sometimes the entire "show" isn't in one vob. I've taken the intro from one recording and joined it to the body of another to make a complete segment. Wish it would support appending more than 1... This feeds 2 VOBs to the IFO creation process resulting in one com bined VOB.

Good, thats what I figured but you put it into words better than I was.

[jdiner]

Sometimes the entire "show" isn't in one vob. I've taken the intro from one recording and joined it to the body of another to make a complete segment. Wish it would support appending more than 1... This feeds 2 VOBs to the IFO creation process resulting in one com bined VOB.
Look at the release notes for the latest version. It now supported an unlimited number of them for attachment. Well for all practical purposes anyway. Since the listbox is used to control the entries you get that as a limiting factor etc... For all practialy purposes I have had 20+ attachments in a single one now.

--jdiner

[jdiner]

Just looking into making updates to the FAQ for 9r14 and was wondering why someone would want to use Attach vob and what it does. I think I know but just want better information.

For general information and for the FAQ in whatever way works best:

The key here is what the process is for TyTool.

TyTool is not a generic DVD system. It is really pretty focused. If you like that focus then you can do things quickly and with great ease for those that don't like a truly generic system like DVDLab is probably better.

Originally in TyTool the premise was take one or more vobs and make a Menu for it and then generate a DVD Fileset for it. So 1 vob meant 1 menu item and 4 VOBs meant 4 menu items. However over time it became clear that at times it is not a 1 to 1 relationship. At times it was necessary to put "pieces" together to make a full show. You can get these pieces for any number reasons: Lean-in part of another recording, several damaged streams being cut together to make 1, unrelated materials that you want put together under 1 menu entry (music videos, commercials, etc...).

So some time ago TyTool was expanded to support the idea of a "main" vob which comes first in the output, and then an attached VOB which was "added" to the end. But only 1 was allowed. I had never tried to make parts from more than 2 source VOB files.

Recently to increase the functionality of the whole thing this was changed and support was added for putting as many VOB pieces as desired into 1 entry and also for being able to order these pieces as desired in multiple passes. I.e. it is possible to add 2 pieces and then go back and add a 3rd and re-order the list to get them into the correct order.

--jdiner

[OutlawPro]

Can you cut a small segment that shows that error? part of why it was not done is that I could not find a way to make it happen here. It is just how data lines up...

Check your PM's. I've sent you a link to download a segment. Let me know if there's anything else I can send you.

[jdiner]

Check your PM's. I've sent you a link to download a segment. Let me know if there's anything else I can send you.
I downloaded it last night. I have just not had the desire to dig into this so far today.

--jdiner

[jdiner]

Woah. I just downloaded the latest version of Media Player. What a pile of trash. Why does anyone try to use that thing?

I could not get it to get rid of the massive borders it wanted to put on the tool itself. No longer a way to go back to the old interface. It kept shrinking the display size of the AVI I was trying to play. And best of all while just playing a few straight WMA files I had it crash 3 times in 4 attempts to play the file.

More than anything this means that I am not going to persue fixing playback for the piece of trash. Even if I got everything perfected odds are it would still crash continuously.

--jdiner

[jdiner]

Check your PM's. I've sent you a link to download a segment. Let me know if there's anything else I can send you.
Alright I just tried it. Not happening here. I am not surprised by that. That issue only arises when line up pretty much perfectly. Since you cut the first 800 chunks off things are now lining up differently. I am going through my TyStream files now looking for one that causes it to happen here.

Hang onto that file.

--jdiner

[malfunct]

I could not get it to get rid of the massive borders it wanted to put on the tool itself. No longer a way to go back to the old interface. It kept shrinking the display size of the AVI I was trying to play. And best of all while just playing a few straight WMA files I had it crash 3 times in 4 attempts to play the file.


I find it incredibly useless for playback of video, but there are vast improvements in the playback of audio. Also there were big improvements in the organization of clips and stuff like that. Its also better integrated with the online things microsoft is pursing.

Unfortunately I think that you are not the target audience of the player, that may be a bad decision, I guess we will see. Like I said I don't use it to play video because it sucks so bad at it.

I have no argument with you not fixing your mpeg output to run in the player, though I have a feeling as you discover whats making codecs in general dislike your mpegs that WMP support will fall out of it. I say don't worry about it though.

[OutlawPro]

Alright I just tried it. Not happening here. I am not surprised by that. That issue only arises when line up pretty much perfectly. Since you cut the first 800 chunks off things are now lining up differently. I am going through my TyStream files now looking for one that causes it to happen here.

Hang onto that file.

--jdiner

I had to delete the full file for space reasons. However, if you want, I can mail you a DVD with the next full file that has the problem. It should only take me a days worth of recording to come across another one since it seems like every show I pulled off with 9R14 experienced it.

[OutlawPro]

Woah. I just downloaded the latest version of Media Player. What a pile of trash. Why does anyone try to use that thing?

I could not get it to get rid of the massive borders it wanted to put on the tool itself. No longer a way to go back to the old interface. It kept shrinking the display size of the AVI I was trying to play. And best of all while just playing a few straight WMA files I had it crash 3 times in 4 attempts to play the file.

More than anything this means that I am not going to persue fixing playback for the piece of trash. Even if I got everything perfected odds are it would still crash continuously.

--jdiner

Crashing aside (it definately happens more than it should) the other problems you are experiencing are just configuration issues. If you want it to look like the old WMP, go to "Skin Mode" and pick the "Classic" skin. I like "Coporate" myself. Also do View -> Video Size - 100%. I turn off "Fit Video To Player On Resize" and "Fit Player To Video On Start" in that same menu. I agree though, it's not one of the best players out there. The WMV9 encoder is probably the best encoder out there right now though. Nothing beats it for streaming over the Internet for sure. Quality wise per size, it beats mpeg2 hands down and runs a constant neck and neck race with Xvid and Divx. Add that to the fact it's part of the DVD-HD spec, there will be no getting away from it.

[jdiner]

I just wish it was more stable. I looked at the time for the option you mentioned. But I have already uninstalled it. I have little patience for software that poorly written.

Having said that I have a number of AVIs from various sources that I play with the old version. The 6.X version of it I am using is simple but extremely robust. Proof that MS can do it right but for some reason isn't right now.

On one of my other machines I upgraded to 7.X and it worked for the install but only sort of and it smashed the files needed for upgrade/repair/removal. Crashes the uninstaller before anything is actually done.

Some will disagree, but I have little appriciation for that program in any of the new versions. That has nothing to do with the codecs themselves but rather with the tools usability.

--jdiner

[jdiner]

I had to delete the full file for space reasons. However, if you want, I can mail you a DVD with the next full file that has the problem. It should only take me a days worth of recording to come across another one since it seems like every show I pulled off with 9R14 experienced it.
See that amazed me. Seriously amazes me. I just processed to VOBs 114 1-hour Tystreams. I did not have it happen once.

Honestly the reason I had thought it was pulled is that it has never once shown up here. The fact that is it for you is pure dumb luck. But I will take it. Because I need a file to test with. I was in the process of looking at making bad files manually to try and make it happen.

--jdiner

[firemunky]

What is your tivo prompt? It sounds like you haven't set your prompt (get at least 9r13c) and the procedure is stuck waiting for a default prompt that will never come.

I wasn't sure what to put there.
When I telnet to the tivo the first prompt I get is: tivo:/var/tmp$

I put tivo: as the prompt and now it's communicating with it at least. I'll reboot the unit and try it now. This will be great for my brother who is let's say less than savy!
Thanks!

[malfunct]

I wasn't sure what to put there.
When I telnet to the tivo the first prompt I get is: tivo:/var/tmp$

I put tivo: as the prompt and now it's communicating with it at least. I'll reboot the unit and try it now. This will be great for my brother who is let's say less than savy!
Thanks!

As the FAQ says you put in a substring of your prompt. I put $ (my prompt is the same as yours) but tivo: is equally valid as is any other substring of the prompt. Just make sure its something that comes up the same every time you boot, /var/tmp is not a good candidate because it may be very unlikey (near to impossible) but you might start up in a different path than tmp.

[BubbleLamp]

The Free Space doesn't change if you switch to a different drive unless you stop and restart TyTool.

[jdiner]

The Free Space doesn't change if you switch to a different drive unless you stop and restart TyTool.
No it is updated only when activity to the drive, most noteably, a download takes place. I din't tie it into the local dir selector or to the text field. I suppose I could but I was trying not to eat CPU cycles with a timer etc... but to only process when something has changed. But a change to the output directory really should be enough.

--jdiner

[malfunct]

No it is updated only when activity to the drive, most noteably, a download takes place. I din't tie it into the local dir selector or to the text field. I suppose I could but I was trying not to eat CPU cycles with a timer etc... but to only process when something has changed. But a change to the output directory really should be enough.

--jdiner

You should be able to hook an OS event to see when that folder's free space changes shouldn't you? That shouldn't eat too many cycles.

[BubbleLamp]

You should be able to hook an OS event to see when that folder's free space changes shouldn't you? That shouldn't eat too many cycles.
I'd worry that approach would eat more, since almost anything could trigger a change. Using the change dir to refresh seems like the simplest. Again, it's no big deal, I'd put it way down on the to-do list, far below the vsplit update. :D

(You knew I wouldn't let you forget that Josh.) ;)

[malfunct]

I'd worry that approach would eat more, since almost anything could trigger a change. Using the change dir to refresh seems like the simplest. Again, it's no big deal, I'd put it way down on the to-do list, far below the vsplit update. :D

(You knew I wouldn't let you forget that Josh.) ;)

I figure its pretty cheap since the standard file dialog uses it as does any explorer window and I don't notice any appreciable lag due to the updates. Maybe they poll but I was sure it was event driven.

[FredThompson]

The WMV9 encoder is probably the best encoder out there right now though.Not according to the tests of the A/V hackers. Look at doom9, everwicked, etc. People who get paid to carry M$ advertising like WMV9, though.Nothing beats it for streaming over the Internet for sure. Quality wise per size, it beats mpeg2 hands down and runs a constant neck and neck race with Xvid and Divx.Depends on the nature of the video source...Add that to the fact it's part of the DVD-HD spec, there will be no getting away from it.Not yet it isn't. M$ is trying to buy their way in to force the format. Don't forget the DRM lockdown and proprietary licensing which attempts to gain ownership of the content for M$...

[BubbleLamp]

I figure its pretty cheap since the standard file dialog uses it as does any explorer window and I don't notice any appreciable lag due to the updates. Maybe they poll but I was sure it was event driven.
I'll defer to your superior knowledge, I'm not a programmer.

[OutlawPro]

See that amazed me. Seriously amazes me. I just processed to VOBs 114 1-hour Tystreams. I did not have it happen once.

Honestly the reason I had thought it was pulled is that it has never once shown up here. The fact that is it for you is pure dumb luck. But I will take it. Because I need a file to test with. I was in the process of looking at making bad files manually to try and make it happen.

--jdiner

Told you it wouldn't take long. :) The first show of the day has the problem. Shoot me a PM of where to send to and I'll get it out to you tomorrow.

[OutlawPro]

Nevermind. In the spirit of keeping the thread on topic and me remembering that I have nothing to prove and best of all nobody really cares, I've deleted what I had to say. Just remember that everything you think is your own opinion and that it might not agree with the person sitting next to you. But that diversity is what keeps the world going around.

[BubbleLamp]

BTW... spelling Microsoft with the M$ just annoys me to all ends of the earth and back. We live in one of the only countries that don't applaud a company for starting from nothing and becoming successful. Instead we try to find ways to tear it down and make it not so successful. If it were a company in Japan or someplace else, they would be get a pat on the back and told nice job. Last time I checked, the goal of a company is to make money.
Even if that company used many quasi-legal or unethical means to get there? I'm all for good companies getting their rewards. I don't like companies that use the "anything we can get away with" mode to succeed. And yes, I do have first hand experience seeing that in action.

[jdiner]

I figure its pretty cheap since the standard file dialog uses it as does any explorer window and I don't notice any appreciable lag due to the updates. Maybe they poll but I was sure it was event driven.
Actually in this case it is incredibly expensive. It is a COM based feature and it I am using neither COM nor MFC. The cost of adding those to the exe is prohibitive.

There are better ways to go about it. A standard Timer event would be far less costly.

--jdiner

[modistru]

... or you could just refresh the static field upon return from the directory navigation dialog :)

But a timer would keep it refreshing during xfer/creation operations, indeed.

[BubbleLamp]

... or you could just refresh the static field upon return from the directory navigation dialog :)

That was what I had in mind, no need for a timer. I'm all for avoiding loops/timers.

[Perogi]

When encoding for DVD with the new mode, the command prompt window opens and stays open with the final line reading: "INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION". Then it just stays there. I cannout make any encoding progress until I close the command prompt window manually. I have to do this numberous times per encode. Is this normal behavior? Am I missing something?

[jdiner]

Told you it wouldn't take long. :) The first show of the day has the problem. Shoot me a PM of where to send to and I'll get it out to you tomorrow.
Amazing. Alright. Check your PM box.

--jdiner

[Perogi]

Sorry...***** points for me...I just needed to replace my cygwin1.dll with the newer version...sorry guys!

[arthur]

This is the code that pulls in the list of fonts:

void menudlgController::ProcessFonts(HWND hwnd, long cb)
{
HDC hDC = GetDC( NULL );

{
LOGFONT lf = { 0, 0, 0, 0, FW_REGULAR, 0, 0, 0, ANSI_CHARSET, 0, 0, 0, 0, 0 };
EnumFontFamiliesEx( hDC, &lf, (FONTENUMPROC)FontProc, (LPARAM)cb, 0 );
}

{
LOGFONT lf = { 0, 0, 0, 0, FW_REGULAR, 0, 0, 0, SYMBOL_CHARSET, 0, 0, 0, 0, 0 };
EnumFontFamiliesEx( hDC, &lf, (FONTENUMPROC)FontProc, (LPARAM)cb, 0 );
}

ReleaseDC( NULL, hDC );
}

The first gets the standard fonts and the second gets things like wingdings etc... A scary proposition, but all of the actual work is done by the Win32 APIs.


hmmm,
strange, attached you will find a quickly written utility based on your posted code that enumerates all the Standard and Symbol Fonts as you coded.
and the following two images are snapshots of the TyTool and EnumFont
Notice how Tytool shows DS-Digital Bold, whereas EnumFont shows Ds-Digital
The strangest part is that, with the above code all bold fonts would be filtered out due to the use of FW_REGULAR constant

It is also worth noting that I loaded the font into Font creator and all the properties showed up correctly.

[malfunct]

Actually in this case it is incredibly expensive. It is a COM based feature and it I am using neither COM nor MFC. The cost of adding those to the exe is prohibitive.

There are better ways to go about it. A standard Timer event would be far less costly.

--jdiner

I will give you that one, it very likely is COM. I never program in C so using COM objects is next to free for me from a code writing standpoint and I never think about that sort of thing one way or another. The only benefit I'd see for TyTool by implementing its interface using standard COM objects is that it would pick up OS style for "free". Of course you have listed all the tradoffs and I agree with them. I only mentioned the directory changed event because I thought it might be easier for you, turns out its not so what you are doing works fine.

[jbc]

Josh, I've got a problem I'm clueless what to search on so I have to ask...

I've got ty files downloaded with 9r11, I've been editing the key file with 9r14. It sounds like tivo side tools got rev'd on r12 and I'm not ready to update those files yet (other problems....).

Here's the setup... 3 hour stanley cup playoff game. I indexed with r14 and attempted to cut the file up. I'd do one period of hockey and check my results. After muxing the file I'd reedit the file, loading the previously saved cut file. Strange thing happens at the start of the third period the index frames seem to be wrong. The first few times editing the file I got evey one of the key I frames. But I was now missing 2-3 of the key frames.

My method for editing was to cut the commercials from the first period, cut intermission crap, and then add a few minutes of the second period cutting from this point to the end of the file. I'd mux the file, check it. I'd choose to edit the key file, load the cut list, delete my last cut and continue to edit.

Reindexing the file I was able to view all the key frames. This latest check I created a new cut file from scratch, saved at the end and then went to mux the stream. (This is good cutfile in the zip)

I'm not sure if this is important, but I've attached the two key files because the end time on one is bad at 13 hours the good one ends at 2:something hours. Are there any known issues with loading cut files?

Any idea what's happening with the cuts?
Thanks!

Edit: looks like the 13h end mark might be ok. I reloaded the "good" edit and noticed the end cut wasn't at EOF. Once I corrrected this I got at time of 13h.

[FredThompson]

with the latest tytool release, generate an IFO set then create a directory within the destination directory, point the destination field to that new directory and attempt to create the IFOs again. Does tytool claim there are existing files in that new, empty directory? It does for me.

[BubbleLamp]

with the latest tytool release, generate an IFO set then create a directory within the destination directory, point the destination field to that new directory and attempt to create the IFOs again. Does tytool claim there are existing files in that new, empty directory? It does for me.
My guess would be that the changed output dir isn't getting registered in the code that checks if it's empty, so it sees your new sub-dir as content, and raises the warning flag. What happens if you close down TyTool and restart it with the new target sub-dir selected, does it then work correctly?

[malfunct]

My guess would be that the changed output dir isn't getting registered in the code that checks if it's empty, so it sees your new sub-dir as content, and raises the warning flag. What happens if you close down TyTool and restart it with the new target sub-dir selected, does it then work correctly?

It works correctly if you exit out (at least when I tested it) I think there is something not getting cleared when you switch directories.

[FredThompson]

Dunno. If this is happening for other people, it's a bug which crept in. Previous version didn't do this.

[jdiner]

with the latest tytool release, generate an IFO set then create a directory within the destination directory, point the destination field to that new directory and attempt to create the IFOs again. Does tytool claim there are existing files in that new, empty directory? It does for me.
And what does this have to do with tivoweb?

The problem is that I set the "here is what everything is" when a change is made to a menu element. The very last thing you did was change the DVD directory. Change a single element in any way, even just select it and then press Set Item and it will work correctly.

That issue is a left over from when you had to manually type the DVD location.

I will add it to the todo list but there is the work around.

--jdiner

[jdiner]

Dunno. If this is happening for other people, it's a bug which crept in. Previous version didn't do this.
Actually it has always been there. Previous versions didn't check things at all.

EDIT: See what happens when I am tired I don't type well... :) The previous versions didn't perform that check at all. It is only in the new ones that you get a popup. So before it would have appended with no notice...

The real problem is that the GUI has expanded beyond what was initially intended and there are a few things within it that are still at the earliest stages. The fixes are not terribly difficult but just kind of got lost in the morass of other issues.

--jdiner

[bschwart]

I've just started using TyTools and love it. One question though, I created a DVD with 4 episodes of a show, everything worked great although on my Toshiba DVD player, the image is skewed off to the left (i.e. the left 1/4 of the frame is on the right side of the television). It works fine on many other DVD players I've tried it on. Any ideas on this.

Brian

[eastwind]

I've just started using TyTools and love it. One question though, I created a DVD with 4 episodes of a show, everything worked great although on my Toshiba DVD player, the image is skewed off to the left (i.e. the left 1/4 of the frame is on the right side of the television). It works fine on many other DVD players I've tried it on. Any ideas on this.

Brian
Research will show you that some DVD players can't handle the resolutions offered by TiVo streams. If you have a SA Series 1, you can change those settings to be more compliant (352x480 or 720x480). If you have a DTiVo, you won't have any luck with it. Might as well replace the DVD player with one of the ones on the known good list (see STICKYs).
ew

[jbc]

Josh, I've been trying to figure out what triggers the strange jump in key frames and here's one way that's worked for me, but... I've only tried twice and it's only worked 50% of the time....

Open key file for edit on its own will allow me to arrow through the frames in the following order
2:01:30.692
2:01:32.594
2:01:35.097
2:01:36.598
2:01:38.000
2:01:39.101
2:01:40.902
2:01:42.304
2:01:44.106

If I open a edit a key file and save cut file, multiplex the file, go back to edit again this time loading the previously saved cut file, go to the 2:01:30 minute mark and arrow through the key frames the frames are at the following markers:
2:01:11.573
2:01:29.291
2:01:45.607


I have also tried the same steps with a 172MB ty file and this worked fine on one test.

Am I doing something wrong or missing something obvious?

[drnull]

Well, we were having an interesting discussion last time about the mpeg2enc blockiness issue before the last thread closed. I'd like to reopen it, if I could.

Part of the problem, I think, is that we have a bit of trouble classifying exactly what the blockiness looks like.

Now, maybe, we can figure this out. Download the attached clip.zip file into your current tytool directory (preferably 9r14, but whatever... Just make sure if you post about it, you specify which version you used.)

Unzip it to find two files:
clip.y4m - just a very small sample clip that will look blocky at q1 on my computer
run.bat - runs mpeg2enc twice, once at q1 and once at q2.

That will output 4 files: clip.q1.m2v, clip.q1.out, clip.q2.m2v, and clip.q2.out

Load those .m2v files into two copies of a program that lets you step frame by frame through a mpeg2 encoded file (I suggest virtualdub-MPEG2 http://fcchandler.home.comcast.net/stable/). Step to frame 3 in both copies and see if your frame 3 looks like this:
q1: http://genome.arizona.edu/~jamie/tivo/mpeg2enc/frame3.q1.jpg
OR
q2: http://genome.arizona.edu/~jamie/tivo/mpeg2enc/frame3.q2.jpg

Obviously, q1 here is the blocky one.

If your q1 is exactly like the blocky one, maybe post with your processor/os/tivo info?

Then, maybe we can compare the .out files and discover something?

Or, maybe we'll just wait for the -q[1,2] to be an option in tytool.

For the record, I'm P4, Win2k, S2 DTivo. (Also had the problem on a P3 & P-M)

[malfunct]

Well, we were having an interesting discussion last time about the mpeg2enc blockiness issue before the last thread closed. I'd like to reopen it, if I could.

Part of the problem, I think, is that we have a bit of trouble classifying exactly what the blockiness looks like.

Now, maybe, we can figure this out. Download the attached clip.zip file into your current tytool directory (preferably 9r14, but whatever... Just make sure if you post about it, you specify which version you used.)

Unzip it to find two files:
clip.y4m - just a very small sample clip that will look blocky at q1 on my computer
run.bat - runs mpeg2enc twice, once at q1 and once at q2.

That will output 4 files: clip.q1.m2v, clip.q1.out, clip.q2.m2v, and clip.q2.out

Load those .m2v files into two copies of a program that lets you step frame by frame through a mpeg2 encoded file (I suggest virtualdub-MPEG2 http://fcchandler.home.comcast.net/stable/). Step to frame 3 in both copies and see if your frame 3 looks like this:
q1: http://genome.arizona.edu/~jamie/tivo/mpeg2enc/frame3.q1.jpg
OR
q2: http://genome.arizona.edu/~jamie/tivo/mpeg2enc/frame3.q2.jpg

Obviously, q1 here is the blocky one.

If your q1 is exactly like the blocky one, maybe post with your processor/os/tivo info?

Then, maybe we can compare the .out files and discover something?

Or, maybe we'll just wait for the -q[1,2] to be an option in tytool.

For the record, I'm P4, Win2k, S2 DTivo. (Also had the problem on a P3 & P-M)

It does look like some values aren't getting cleared when they are supposed to. Also based on the block layout it looks like the problem is in building the blocks and not in arranging them. I wonder if there is some rounding happening in the frequency domain before the conversion back to pixels. Wierd.

[drnull]

It does look like some values aren't getting cleared when they are supposed to. Also based on the block layout it looks like the problem is in building the blocks and not in arranging them. I wonder if there is some rounding happening in the frequency domain before the conversion back to pixels. Wierd.

I was thinking more that for some reason, it was picking the wrong "representation pattern" to represent that block. Now, I'm probably seriously talking out of my rear here (as our beloved deceased janitor would say), as I don't really have a clue about mpeg2 encoding, but I'm pretty sure there's a set of patterns that are used to compress block structures. Course, I really thought those blocks would have been a little smaller (like 8x8, instead of the larger ones we see?)

Actually after looking at it, it does seem that those larger blocks are just made up of 4 8x8 blocks. Yeah, those are the blocks I was thinking about. DCT, somehow, right? (http://tangentsoft.net/video/mpeg/) Anyways, I don't guess that helps us. Just thinking out loud, that's all.

[FredThompson]

Ah, yes, those are mis-behaving DCT. You'll see it on DirecTV transmissions when their encoders screw up during scene changes. FWIW, I've NEVER seen that on my systems, 1200 Durons, 2100 Athlons, Asus A7n8x deluxe and -x mobos, Win2K ('cause XP is WinDummies...)

[drnull]

Ah, yes, those are mis-behaving DCT. You'll see it on DirecTV transmissions when their encoders screw up during scene changes.

True, I see the exact same thing on tv every single day on my local NBC. During the Today show, as they show the local weather, there's an animation where they zoom out to show today's forcast. Anyways, EVERY day, it gets that same blockiness.

Odd that it should occur so predictably, isn't it?

[eastwind]

q1 - Blocky
q2 - Not Blocky
P4 system with WinXP Home

ew

[OutlawPro]

q1 - Blocky
q2 - Not Blocky

P4 HT, WinXP Pro (because I know what I'm doing and know how to configure an OS and know that XP is better than 2K)

The weird thing is, I don't recall ever seeing it in any mpeg I've made. Maybe it's just flying by too quickly. Just to double-check, I tested them both in Nero Showtime using my quickdraw pausing and got the same results.

[drnull]

The weird thing is, I don't recall ever seeing it in any mpeg I've made. Maybe it's just flying by too quickly. Just to double-check, I tested them both in Nero Showtime using my quickdraw pausing and got the same results.

Ahh, right, you're the one that ruined our theory last time!!! :-) Well, thank you very much for taking the time to retest and post results. That could very well settle it as an intel "problem" then.

[jbc]

I was hoping to get a dusty old PC out to try the blocky stuff on, I installed a new 200GB drive and then ran the test with the same results. Q1 is block, then I decided to check the CPU and doh! it's another P3... but damn it's fast with the fast 200GB drive!

So my tests... All on win2k 2 P3s and 2 P4s all intel different mobos all with the same result blocky with q1. I'm really wishing I had a AMD box...

Josh, I'm always willing to try making builds for you. I'm sure there are other more qualified windows folks, but... if not, I can try. Would it be helpful to start grabbing random cygwin1.dll files and test those with mpeg2enc?

[ronnythunder]

drnull, tried your test on my box, and both versions of the clip look exactly the same (no blockiness)

i'm running an amd athlon xp1700+ with windows 2000 sp3.

ronny

[jdiner]

Ahh, right, you're the one that ruined our theory last time!!! :-) Well, thank you very much for taking the time to retest and post results. That could very well settle it as an intel "problem" then.
Welcome to the wonderful world of AMD... :)

I also just ran the test. Had to edit the .bat file to point to the right directory since I don't have TyTool or mpeg2enc in my path.

I get perfect compressions in both modes. At -q1 I get a file 204k in length. At -q2 I get 194. Visibly when looked at side by side there is an ever so slightly present change in the quality of the output.

I do believe that the key is the Intel CPU. I think we should bring it up with the cygwin people directly. As in taking a brief look at the code there is only 1 MMX file for the mpeg2enc people. I.e. not one for AMD and one for Intel. So my guess is that it is the underlying compiler architecture in use that is the culprit.

--jdiner

[jdiner]

Look for a new Win32 and Linux port of VSplit caught up with the current fixes of TyTool in the next 24 hours or so. Going to try and fix something in the new muxer first and then get it out the door.

The core issue here is solving an error in the new muxer. If what I have in mind does not work I will just be making the release without that fix.

I would try and get it out tonight but I was just trying to test a process on something else and found that I was 0 bytes free on a 500gig raid array. Wow... 4 drives, 1 partition, 100% full.

Back in my Amiga days I would never have thought it possible. I used that A3000 with only 105meg HD space total. :)

--jdiner

[malfunct]

I just ran the mpeg2enc test on my machine and I don't have blocks. Dual Athlon MP 1900+ here.

[Waruwaru]

Back in my Amiga days I would never have thought it possible. I used that A3000 with only 105meg HD space total. :)

haha, I think I paid more than $200 for the 80 meg SCSI drive on my A1000. Those were the days... :)

[drnull]

I do believe that the key is the Intel CPU. I think we should bring it up with the cygwin people directly.

--jdiner

Interesting: I just compiled mpeg2enc on a linux RH9 system also running a P4. Ran the same test at q1 and DO NOT get blocks. It seems, though, that you already knew it was related to cygwin directly and not related to the intel/amd chip itself.

Compiling mpeg2enc on my cygwin gave me fits, haven't got it working yet...

[FredThompson]

haha, I think I paid more than $200 for the 80 meg SCSI drive on my A1000. Those were the days... :)Whipsersnapper! I remember magnetic cores. Didn't own one, mind you. The first I had was an Atari 800 with 3 16K modules and a tape drive.

Now someone will reply to this post and talk about their Altair...

[BubbleLamp]

Back in my Amiga days I would never have thought it possible. I used that A3000 with only 105meg HD space total. :)

--jdiner

My 1000 had two floppies drives, and blank disks were $36/box!! Geez I never should have sold that machine, amazing hardware.

I have a $1000 500MB drive around here somewhere, VIC20 with tape drive too. Sold the C64 and C128 ages ago.

[rung]

My 1000 had two floppies drives, and blank disks were $36/box!! Geez I never should have sold that machine, amazing hardware.

I have a $1000 500MB drive around here somewhere, VIC20 with tape drive too. Sold the C64 and C128 ages ago.

I had a 10 MB external Winchester harddrive for my TRS80. It was the same size as my Tivo! I was so happy to not have to boot off of floppies.

[laserfan]

My 1000 had two floppies drives, and blank disks were $36/box!! Geez I never should have sold that machine, amazing hardware.

I have a $1000 500MB drive around here somewhere, VIC20 with tape drive too. Sold the C64 and C128 ages ago.Sorry, I think I have you all beat. The 16K RAM board (yes, 16,000!) cost $700 for my IMSAI 8080 (circa 1976), and the dual 8" floppy drive for the thing cost two grand. Still have it, maybe someday I will fire it up again and try to run TyTool on it. ;)

[malfunct]

My 1000 had two floppies drives, and blank disks were $36/box!! Geez I never should have sold that machine, amazing hardware.

I have a $1000 500MB drive around here somewhere, VIC20 with tape drive too. Sold the C64 and C128 ages ago.

Ikes, why did you go and do that? I still have most of the computers I had when I was young and those that got lost along the way I have repurchased. My only hopes is that I can keep my wife from making me get rid of them, she doesn't understand why I want them around.

I do need to get all of my floppy disk software backed up to a more permanent media at some point though.

As for the price of my PC's, I was always about 4 or 5 years behind the curve so I don't think my parents paid more than $200 for any that they got me. It wasn't until I bought my own 486 that I had a computer that was purchased for more than that.

[BubbleLamp]

Ikes, why did you go and do that? I still have most of the computers I had when I was young and those that got lost along the way I have repurchased.
Yea, well at the time I needed the $$. But I've thought about getting a C64 from time to time.

Note to Josh, maybe you can break off this severely off topic portion of the thread and move it to the Chit Chat section.

[drnull]

Compiling mpeg2enc on my cygwin gave me fits, haven't got it working yet...

Well, tried the latest dvdauthor version of mpeg2enc.exe and got the same blockiness.

So, fought more with compiling it myself.

make fails in the mplex directory (no biggie, but I wanted to make it all work), so you can either change the makefile to include libmjpegutils.a (and your changes will be blown away if you configure again), or just go to the mplex directory and do
../libtool --mode=link g++ -mcpu=i686 -march=i686 -g -O2 -o mplex.exe main.o ../mplex/libmplex2.la -lm ../utils/libmjpegutils.a
yourself, then start the make up again and let it finish.

made two very small changes to mpeg2enc/motionest.cc (added (uint32_t*) twice on two lines) and got past compile errors, but got a seg fault from ld when linking (wha???)...

then read:
http://mail.gnu.org/archive/html/vcdimager-gui-devel/2002-01/msg00004.html
that simd extensions were error prone (as jdiner also pointed out) in cygwin. So, did a ./configure --disable-simd-accel. Guess this would also make my executables compatible with amd chips?

Anyways, the long and short of it is, generated a new mpeg2enc.exe, and it PASSED the q1 test (it also didn't matter which cygwin1.dll was used... mine from my cygwin install or jdiner's from the tytool install, just like with the other mpeg2enc, I got blockyness from both cygwin1.dll's)

Attached the mpeg2enc.exe I generated and my cygwin1.dll (anybody with amd wanna give this a shot and see if it's broken for you now?) One big question, though, is have I introduced any of the gridding effects that we were seeing back a while ago? (http://www.dealdatabase.com/forum/showpost.php?p=155265&postcount=459 et al). Does anybody still have clips where the gridding effects are KNOWN to occur when something isn't right?

ugh. Who knows. JDiner, if you want me to drop this as you are looking to move to something besides mpeg2enc (and cygwin), let me know and I will. Otherwise, if we're gonna be here awhile, it'd be nice to find something that works correctly for everyone at q1.

I've dropped it into my tytool directory, and it works fine being called directly from tytool also (at q1 still). Anybody else want to try? If you do, and it causes problems, just use your backups or redownload 9r14.

[jdiner]

DrNull:

If you think you can fix the MMX/SSE portions of the Cygwin compiler then by all means do so. Many would thank you for it.

Getting it compiled is a serious pain. Took me a long long time as well.

However, if all you are really looking for is a non-MMX/SSE version then Pete Hatcher (I think I have that right) posted such a version awhile back. I have yet to see anyone post the recent tests with this version of mpeg2enc but hopefully someone will. It would be nice if people had that simple of an alternative.

--jdiner

[jbc]

Thanks Dr. Null you got that done quicker than I did. =)

I can say it does work great on a P3. It is a lot slower, but it is correct.

[drnull]

I can say it does work great on a P3. It is a lot slower, but it is correct.

Yeah, much slower, tragically. Wish we could pick and choose what parts were disabled. Maybe it's just one particular set that we could disable to fix it.

Just for the record, I was using the latest release of mjpegtools (1.6.2) and cygwin version (1.5.9)

JDiner:
Drat, I had forgotton about that post by Peter Hatch... Just tried it, and his version also passes the q1 test. No blocks.

So you mean I wasted all that time getting mjpegtools to compile for nothing?? Nah, I learned a little while I was at it I guess. :-)

[bato]

JDiner:
Drat, I had forgotton about that post by Peter Hatch... Just tried it, and his version also passes the q1 test. No blocks.
IIRC (maybe I'm not) the Peter Hatch files created some gridding efect on jdiner's machine.

BTW no blocks in my AMD (if anyone cares at this poing :) ).

[OutlawPro]

Back in my Amiga days I would never have thought it possible. I used that A3000 with only 105meg HD space total. :)
--jdiner

Yeah, no kidding. Funny thing too because I have an A2000 with monitor sitting in the floor behind me and I have been debating for a week whether to put it on ebay or just toss it in the dumpster. I just don't have the heart to do that since it still runs and works fine except for a mouse port issue.

I remember buying a 800MB HD that cost nearly $800. I also had one of those SCSI 10MB floppy drives. And..remember the little "legs" on that A3000 memory that would break off if you even looked at it sideways.

[malfunct]

Yeah, no kidding. Funny thing too because I have an A2000 with monitor sitting in the floor behind me and I have been debating for a week whether to put it on ebay or just toss it in the dumpster. I just don't have the heart to do that since it still runs and works fine except for a mouse port issue.

I remember buying a 800MB HD that cost nearly $800. I also had one of those SCSI 10MB floppy drives. And..remember the little "legs" on that A3000 memory that would break off if you even looked at it sideways.

Send it to me :)

[jdiner]

IIRC (maybe I'm not) the Peter Hatch files created some gridding efect on jdiner's machine.

BTW no blocks in my AMD (if anyone cares at this poing :) ).
That gridding was the latest version of the cygwin1.dll. If you rolled back to what is in use in the TyTool releases then the gridding was not present.

I didn't release with it because I was unaware until the last 24 hours that there really was that strong a tie between everything. And to be honest it is SOOoooOOOooo much slower it would drive most people nuts.

I think the key at this point is to put an option in TyTool that will allow users to pick Q1 and Q2 depending on the CPU. Might even be a good time to find some code for detecting what CPU it is and auto-setting that default based on where it is running. Anyone got any CPU maker detection code?

--jdiner

[FredThompson]

Anyone got any CPU maker detection code?

Look at ProcessorNameString in HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 if the system is Win2K.

[malfunct]

That gridding was the latest version of the cygwin1.dll. If you rolled back to what is in use in the TyTool releases then the gridding was not present.

I didn't release with it because I was unaware until the last 24 hours that there really was that strong a tie between everything. And to be honest it is SOOoooOOOooo much slower it would drive most people nuts.

I think the key at this point is to put an option in TyTool that will allow users to pick Q1 and Q2 depending on the CPU. Might even be a good time to find some code for detecting what CPU it is and auto-setting that default based on where it is running. Anyone got any CPU maker detection code?

--jdiner

Just need to get the CPUID and look it up in a table. Search the web, I bet the algorithm is out there like 50 times.

EDIT: A couple of useful links I just found -

http://faydoc.tripod.com/cpu/cpuid.htm

http://grafi.ii.pw.edu.pl/gbm/x86/cpuid.html

[jdiner]

I found a proper explanation of how to do it on the web. It is just never something I have had to worry about before. So much for "all things being equal" when it comes to the various CPUs...

--jdiner

[malfunct]

I found a proper explanation of how to do it on the web. It is just never something I have had to worry about before. So much for "all things being equal" when it comes to the various CPUs...

--jdiner

Whats worse is that often when a manufacturer releases a new cpu they don't exactly follow the old cpuid format.

[FredThompson]

I've just used the expanded ability to append VOBs. WOW!!! It's fantastic.

One request: can color be added to Menu Elements list to indicate multiple-VOB entries?

[tweaky]

Not sure if this belongs here, but does anybody know how to change the menu element colors?

[malfunct]

Not sure if this belongs here, but does anybody know how to change the menu element colors?

Check FreeThopmson's thread on tytool enhancements. Changing the colors is not supported inside tytool but can easily be done using the applications provided with tytool.

[FredThompson]

Why does the key file now enforce a hard path to the ty file?

[jdiner]

Why does the key file now enforce a hard path to the ty file?
I have covered this in the past.

In GOP mode the Key file is completely independant.

In FAE mode the key is used with the source file to get the full data for a GOP. So you can see each frame/field.

Without putting the name in the key file you can't put things in different places. I.e. it defeats having the "set output directory" functionality.

Yes it limits movement after making the key file but 99% of the time this never happens. When it does just remake the key file.

--jdiner

[FredThompson]

I have covered this. Why do we keep looping around to the same questions...Because I'm braindead.

[jdiner]

Because I'm braindead.
No it isn't just you. I have gotten a ton of PMs lately asking to the things we covered as a group.

3 in the last week asking for TyTool to auto-start the server. We went around and around on that one just a few days ago as to what was best.

I also should not bother trying to read up on this stuff minute after getting home from a 2 day trip. Traveling like that is just a touch to frustrating all on it own.

--jdiner

[FredThompson]

Josh,

I've got a bunch of GOP-edited MPEGs which were muxed with an old version of TyTool.

Is there any risk to running them through TyTool to remux using the new method to make VOBs? You've mentioned the MPEG input is weak and also made some comments about some upcoming improvements to the muxing.

--

You're gonna kill me for asking this again. I plead the memory retention of an old man ;)

What's the technical reason TyTool can't dump m2v and mpa if audio holes are patched?

[jdiner]

I've got a bunch of GOP-edited MPEGs which were muxed with an old version of TyTool.

Is there any risk to running them through TyTool to remux using the new method to make VOBs? You've mentioned the MPEG input is weak and also made some comments about some upcoming improvements to the muxing.
Risk? No. Only that the process won't work. It not like it freaks and wipes the hard drive or anything. TyTool can just crash if things get confused enough. If it can process them, and it often will, then you are good to go.

The problem is that it is really no better than about 95%. Usable but the warning was primarily for those that were using MPEG as the download format. Doing so meant about 1 in 10 weren't going to work further and so it should be avoided.

You're gonna kill me for asking this again. I plead the memory retention of an old man ;)

What's the technical reason TyTool can't dump m2v and mpa if audio holes are patched?
You can patch the audio holes, and in fact you should. It just doesn't make much difference if you are editing. The problem is that the editing process creates holes that can not be filled correctly. So if you go to ES files and edit then you are going to get tiny holes in the audio at the cut points.

Since you get seperate output files under the split process, one between each cut, each one has a seperate alignment between the audio and video segments.

What you can't do is get 1 single Audio and 1 single Video file that has been edited.

--jdiner

[FredThompson]

I should have chosen more appropriate words. IIUC, you say if TyTool doesn't crash, a VOB created from an MPEG should be fine, correct? My thought was more along the lines of corruption in the output which wouldn't be evident until the VOB is played.

wrt cuts and elemental streams, ok, I understand. Nuts. Was hoping there would be a way to do FAE then make elementals so sound can be cleaned up on old, noisy source.

[jdiner]

I should have chosen more appropriate words. IIUC, you say if TyTool doesn't crash, a VOB created from an MPEG should be fine, correct? My thought was more along the lines of corruption in the output which wouldn't be evident until the VOB is played.

wrt cuts and elemental streams, ok, I understand. Nuts. Was hoping there would be a way to do FAE then make elementals so sound can be cleaned up on old, noisy source.
Unless TyTool crashes the output VOB will be just fine.

On the audio work. No. That is not really within the scope of the target for TyTool. Audio transcoding was originally unplanned and only the exceptional work from Rowan really made it possible in the first place.

--jdiner

[FredThompson]

Gotcha. It's still a fantastic benefit to get those old MPEGs safely into VOB and burned. Woohoo!!

[FredThompson]

Josh,

(This is a little wordy. I'm trying to ensure all the points are covered and I've thoroughly explained the idea.)

Am I correct in understanding your comment a few posts ago to mean as long as there are no cuts WITHIN a VOB it would be fine to break it into elementals, process the audio, then remux as long as audio holes are patched? Would that include FAE cuts on the front and tail ends?

To illustrate the idea, imagine an early film which has some intro and outro commentary. This starts as a ty and it then cut into 3 distinct VOBs using GOP or FAE cuts at the start and end of each section, as needed. Audio holes are filled. All segments are contiguous with no internal edits.

OK, the early film portion is split into elementals, the audio processed, then they are muxed. The three portions are combined again within TyTool's menu creation dialogs which allows concatenation of VOBs.

Will this work or is it subject to error if there are leading/trailing FAE cuts?

[FredThompson]

Would someone please explain to me how to tell if a ty has a DD component? If this is something which can be determined during the key creation phase, perhaps it would be useful to store that status within the key and some form of indicator shown when the files are accessed by TyTool. IOW, when you're looking at a pick list and the keys are made, those which have DD are indicated by boldness or color, something like that.

[malfunct]

Would someone please explain to me how to tell if a ty has a DD component? If this is something which can be determined during the key creation phase, perhaps it would be useful to store that status within the key and some form of indicator shown when the files are accessed by TyTool. IOW, when you're looking at a pick list and the keys are made, those which have DD are indicated by boldness or color, something like that.

JDiner put up a program that can do that. I think its called audiocheck or something to that effect.

[Pendragn]

I apologize if this has been covered before.

I just put TyTool in C:\Program Files\TyTool and put that directory in my path statement. I copied all the relevant files there, I had been using them in a different directory. I moved to C:\temp\tivo fired up tytool. It didn't use the tytool.ini from c:\program files\tytool, but created its own, in C:\temp\tivo. Is that by design?

tk

[larray]

Josh,

I'm going to try to keep this in the "dull roar" category :)

I've found a few issues with 9r13 and 9r14 that I wanted to bring up and see if there was any chance that they were being looked at. I'd previously been using 9r8, then recently noticed 9r13 and 14 come out. Dowloaded 9r13 noticed the problem, and then noticed 9r14 and did all of my testing there.

I'm extracting via mfs_ftp to TMF (quick dump to longer term storage until I have the time to mess with getting it on DVD). System is a Dell 530 Dual 1.5 running XP with 2 gig of RAM.

The TMF files I have I've used 9r8 on and do not have the issue.
1) FAE cuts bomb GOPEditor flat cold - the second I try to enter into FAE mode it comes up with Windows reporting error. (Yes, I do have the cygwin dll in my folder - I even tried putting it in my system path).
2) I can carry the process through without FAE and "old school" "Multiplex files" (like under 9r8) and audio option #7 (really like the concept of #8!). However the MPEG output can no longer be used under the relaxed multiplexer in DVDLab. The error I get is "The MPEG file has an encrypted video stream. The file cannot be demuxed". Under 9r8 it works great still. In one test, I could demux with TMPGEnc, but I never carried it to completion to see if I could generate a DVD.

I don't want this to sound like I'm whining or complaining, it's more of a question of if support for the older method could be added in without too much cost to the app. I know you have a direction for what you are doing and respect that. I just want to know if I'm now going to be stuck using 9r8 to keep my workflow flowing. :D

Other than that - great work, love the new features of 9r14, just wish that they worked for me!

Andy

[jdiner]

Am I correct in understanding your comment a few posts ago to mean as long as there are no cuts WITHIN a VOB it would be fine to break it into elementals, process the audio, then remux as long as audio holes are patched? Would that include FAE cuts on the front and tail ends?
No. There are many sources of holes and most of them are not, or can not be, corrected perfectly. Damaged streams etc...

If you split things out, getting them back together is problematic. Hence the reason I put so much effort into the internal muxer.

--jdiner

[jdiner]

Would someone please explain to me how to tell if a ty has a DD component? If this is something which can be determined during the key creation phase, perhaps it would be useful to store that status within the key and some form of indicator shown when the files are accessed by TyTool. IOW, when you're looking at a pick list and the keys are made, those which have DD are indicated by boldness or color, something like that.
This falls into the category of something you are going to have to monitor yourself.

You can use audiocheck to monitor a specific TyStream after downloading. Most of the time it is easy to tell from the name of the show itself. Episodes of TV usually NOT Dolby, movies usually there.

With the new audio conversion mode, #8, it is not that hard to deal with for people that prefer/want Dolby.

I will not be changing the requestor to colorize the lists in it based on audio type. I believe in using color sparingly as it becomes nothing but a distraction if used other than sparingly.

--jdiner

[jdiner]

I just put TyTool in C:\Program Files\TyTool and put that directory in my path statement. I copied all the relevant files there, I had been using them in a different directory. I moved to C:\temp\tivo fired up tytool. It didn't use the tytool.ini from c:\program files\tytool, but created its own, in C:\temp\tivo. Is that by design?
The tytool.ini file is loaded from the same directory as the executable was run from. If it created a new one in c:\temp\tivo then that is where it thought it was run from. I can't tell you why...

My guess when you tried to create icons it was not a shortcut but rather an copy of the EXE.

My advice. Do a completely new and clean extraction into the new directory. Don't make icons or drag things around. Run the exectuable from there using a dos shell make sure the setting are correct in the GUI and exit. Check the .ini file to make sure the changes were kept. Then try making the icon and you should find whatever your problem was.

--jdiner

[jdiner]

The TMF files I have I've used 9r8 on and do not have the issue.
1) FAE cuts bomb GOPEditor flat cold - the second I try to enter into FAE mode it comes up with Windows reporting error. (Yes, I do have the cygwin dll in my folder - I even tried putting it in my system path).

GopEditor DOES NOT SUPPORT TMF FILES IN ANY WAY. I have said this many many times. GopEditor supports .TY FILES ONLY.

If it ever worked you got lucky. The fact that it does not work now is not on purpose merely a side of effect the layout of the file, the layout of the editor, changes to the editor to add the new features, etc...

--jdiner

[FredThompson]

I'm extracting via mfs_ftp to TMF (quick dump to longer term storage until I have the time to mess with getting it on DVD). If you're going to DVD/MPEG2 and want to use TyTool, use tserver and extract via TyTool.

[FredThompson]

This falls into the category of something you are going to have to monitor yourself.

You can use audiocheck to monitor a specific TyStream after downloading. Most of the time it is easy to tell from the name of the show itself. Episodes of TV usually NOT Dolby, movies usually are.

With the new audio conversion mode, #8, it is not that hard to deal with for people that prefer/want Dolby.

I will not be changing the requestor to colorize the lists in it based on audio type. I believe in using color sparingly as it becomes nothing but a distraction if used other than sparingly.It's not always obvious with older movies, that's why I'm asking about this stuff. The old B&W may have multiple tracks besides a mono or stereo. There were all kinds of multi-channel tracks pre-Dolby and it's not always clear with films during that time what the content might have. IIRC, Disney's Fantasia had something like 11 channels. Yes, anything from the premium movie channels is probably DD.

So...there is no automated way to make a DD output if the input contains DD, stereo otherwise and I should probably run AudioCheck on a dir and pipe the output to a file for further processing to see if anything in the dir is DD. (yes, I'm going to write this up as a recursive script and post it when it's working...)

Will AudioCheck distinguish between mono, stereo, and DD or just stereo and DD. I don't get any of the premium movie channels and don't have DD equipment. My concern is losing any DD which is present because I don't know it's there. I get this at the top of one scan:


checkNumRecs: Number of Records: 18165 (f5 46 7a bd)
Main Pump: Bad Chunk! Skipping!

checkNumRecs: Number of Records: 204 (cc 0 2 80)
LayerII Audio segment starts at chunk #: 1
When DD is detected, what does the line look like? Is there a non-documented mode to do a compact display or is it always status per chunk? Is there a way to calculate the timeoffset within a file based on chunk number?

I don't really care how the status is shown, I'm just looking to develop a method to look at a batch of files and know what the content is. That's where the color idea came from. The idea was if someone wants DD and that's a valid option because it's in the source, it seemed a natural thing for the tools to enforce for them given they're going to scan each stream to make keyfiles. IOW, flag the status while the keyfile is being made, if the user sets the "DD if present" setting and the status was set, give them DD. OVerrides would still work but it helps dummyproof...uh...or maybe I-don't-want-to-always-have-to-remember-it-itis...

There's also a lack of knowledge/experience on my part about DD. If someone who works with this a lot would give me some pointers and explain, I'd sure appreciate it. Frankly, I'm confused as to why I would care when a stream changes to DD.

Another thing I'm wondering about is when there are multiple programs in a ty and, for example, #2 of a 3-program ty is DD and #1 and #3 aren't, how would you detect this?

[larray]

GopEditor DOES NOT SUPPORT TMF FILES IN ANY WAY. I have said this many many times. GopEditor supports .TY FILES ONLY.

If it ever worked you got lucky. The fact that it does not work now is not on purpose merely a side of effect the layout of the file, the layout of the editor, changes to the editor to add the new features, etc...

--jdiner

I apologize, my bad. I went back and re-read this thread from the beginning and seem to have missed where the TMF files were not supported. I think I heard the rumor wayyyyyyyy back in the 8r(x) days that TMF was now supported, tried it and was pleasantly supprised when it worked till now. :D

I guess it bears repeating since I couldn't find reference in this thread or on the TyTools site.

I'll re-test with TY files. Is this TY files ONLY that are extracted with TyTool, or are the TY files that MFS_FTP produces kosher for TyTool?

Thanks!!

[Pendragn]

The tytool.ini file is loaded from the same directory as the executable was run from. If it created a new one in c:\temp\tivo then that is where it thought it was run from. I can't tell you why...

My guess when you tried to create icons it was not a shortcut but rather an copy of the EXE.

My advice. Do a completely new and clean extraction into the new directory. Don't make icons or drag things around. Run the exectuable from there using a dos shell make sure the setting are correct in the GUI and exit. Check the .ini file to make sure the changes were kept. Then try making the icon and you should find whatever your problem was.

--jdiner
There were no icons or shortcuts involved. It was all done from cmd.exe. The only change I made was to copy tytool9r14.exe to tytool.exe in C:\program files\tytool. That was so I could just type "tytool" without having to remember which revision was latest. The directory where I typed "tytool.exe" was c:\temp\tivo. There are no .exe files there, the system is finding tytool.exe in the path statement, and running it out of c:\program files\tytool.

Does that shed some light on it? It's not a huge deal, and certainly not something I can't work around. It just smelled a bit like something you might want to look into. It's a pretty small thing though, I can see other issues being much higher on the priority list. :)

tk

[malfunct]

There were no icons or shortcuts involved. It was all done from cmd.exe. The only change I made was to copy tytool9r14.exe to tytool.exe in C:\program files\tytool. That was so I could just type "tytool" without having to remember which revision was latest. The directory where I typed "tytool.exe" was c:\temp\tivo. There are no .exe files there, the system is finding tytool.exe in the path statement, and running it out of c:\program files\tytool.

Does that shed some light on it? It's not a huge deal, and certainly not something I can't work around. It just smelled a bit like something you might want to look into. It's a pretty small thing though, I can see other issues being much higher on the priority list. :)

tk

Its the same problem as the shortcut issue, you ran the program in the wrong working path and so it needed to create a new .ini file which is the correct default behavior. This is not a supported scenario (nor do many other program support you putting thier exe in a different directory than the support files and then trying to run them). Worse is that even if you have all the support files in the same directory as tytool.exe, because you are starting it from a different directory than the support files you have the same issue because your working directory will be set wrong.

Anyways, two ok ways to deal with this. First is create a shortcut to tytool in the correct directory and make sure its working path is set to the tytool directory and use that shortcut to start up tytool. Or, if you want to start up from the command line at an arbitrary path then you should make a .cmd (windows NT batch file) that calls tytool in the correct working directory and then put that batch file in the path.

Either way you must start tytool with the correct working path and have all of the tytool support files in that working path in order for it to run correctly.

[bato]

I think the key at this point is to put an option in TyTool that will allow users to pick Q1 and Q2 depending on the CPU. Might even be a good time to find some code for detecting what CPU it is and auto-setting that default based on where it is running. Anyone got any CPU maker detection code?
How about default to Q2 but a way to change to Q1? This way all edits will work right, and only people that can see the difference between Q2 and Q1 and know they can use Q1 will change that? I think most people that have the Q1 problem were able to hexedit TyTool to change that to Q2 without problems.

[Pendragn]

Its the same problem as the shortcut issue, you ran the program in the wrong working path and so it needed to create a new .ini file which is the correct default behavior. This is not a supported scenario (nor do many other program support you putting thier exe in a different directory than the support files and then trying to run them). Worse is that even if you have all the support files in the same directory as tytool.exe, because you are starting it from a different directory than the support files you have the same issue because your working directory will be set wrong.
Maybe I'm being unclear. All the executables and support files are in C:\Program files\Tytool.
Only .TY files are in C:\temp\tivo.
C:\Program Files\TyTool is in my PATH environment variable. So I can type TyTool.exe in C:\Temp\Tivo and it will execuate the one in C:\Program Files\TyTool. TyTool.exe and TyTool.ini (as well as all the other support files) are in the same directory, C:\Program Files\TyTool.

Now, having said all that, this just might not work, which is fine. I just didn't know if Josh was aware of it. If he is, and he's comfortable with it, then so am I.

tk

[malfunct]

Maybe I'm being unclear. All the executables and support files are in C:\Program files\Tytool.
Only .TY files are in C:\temp\tivo.
C:\Program Files\TyTool is in my PATH environment variable. So I can type TyTool.exe in C:\Temp\Tivo and it will execuate the one in C:\Program Files\TyTool. TyTool.exe and TyTool.ini (as well as all the other support files) are in the same directory, C:\Program Files\TyTool.

Now, having said all that, this just might not work, which is fine. I just didn't know if Josh was aware of it. If he is, and he's comfortable with it, then so am I.

tk

Still the same working directory issue. Let me see if I can explain.

your files are in c:\program files\tytool and thats in the path. You are at c:\ and type tytool and windows responds by searching the path and finding it. Windows then runs tytool.exe with the working path of c:\ but tytool (by design) needs to run under the working path c:\program files\tytool. Basically you are screwed. The fix is to make a batch file called tytool.cmd that changes directory to c:\program files\tytool and then calls tytool.exe in which case tytool is executed in the correct working directory and all is well. Just make sure that tytool.cmd is in the path and tytool.exe is not so that you force the batch file to run and not the executable directly.

EDIT: BTW its not whether or not JDiner is comfortable with the "problem", this is just how windows works and can't be helped. The only thing that JDiner could do is have a registry setting that specified the location of tytool support files and use that to find things regardless of the working directory. Its a bad solution to something thats not really a problem though. Just start tytool with the correct working directory (which is something most programs require you to do) and everything is fine.

[Rowan]

BTW its not whether or not JDiner is comfortable with the "problem", this is just how windows works and can't be helped.

That is not true, it is very easy for the program to figure out were it is running from. I do it all the time, here is a small code snipit that show show to get the full path of were the exe is running from, you can then append the inf file name and open it. This would make it so the inf file has to be in the same directory as the exe.


TCHAR fileName[MAX_PATH];
::GetModuleFileName( 0, fileName, MAX_PATH );

// remove program name
while ( strlen( fileName ) && fileName[strlen( fileName ) - 1] != '\\' ) {
fileName[strlen( fileName ) - 1] = '\0';
}

At this point fileName has the complete path and you can just add say "tytool.ini" to the end of the string and you have it.

[jdiner]

I apologize, my bad. I went back and re-read this thread from the beginning and seem to have missed where the TMF files were not supported. I think I heard the rumor wayyyyyyyy back in the 8r(x) days that TMF was now supported, tried it and was pleasantly supprised when it worked till now. :D

I guess it bears repeating since I couldn't find reference in this thread or on the TyTools site.

I'll re-test with TY files. Is this TY files ONLY that are extracted with TyTool, or are the TY files that MFS_FTP produces kosher for TyTool?

TyTool supports TMF files much better now. But those are 2 seperate tools.

You can use a tool someone else posted about that was in essence just an untar tool that extracted the data from the file and turned it into 1 single .TY style file. Thus no redownload is needed but more disk space is.

As where it was said:

Check the "What does this mean FAQ" for the entry entitled:

Why can't I FAE edit TMF files? - http://www.tytool.com/TyTemplates/FAQ/what/default.aspx#_-_Why_can't

I believe I made it pretty clear there...

--jdiner

[jdiner]

How about default to Q2 but a way to change to Q1? This way all edits will work right, and only people that can see the difference between Q2 and Q1 and know they can use Q1 will change that? I think most people that have the Q1 problem were able to hexedit TyTool to change that to Q2 without problems.
Why is that we always seem to cater to the few with the problem? Rather than the many that have it working right?

Rather than defaulting to lower quality how about a default of Q1 and an option to go to Q2 if you feel you must?

What I am working on right now is an auto-selection system that detects the CPU type and goes on from there to pick Q2 if you are unlucky enough for this stuff to have an Intel CPU.

The best answer is for someone involved with Cygwin to fix things but from what I have read it isn't even on the horizon at the moment.

--jdiner

[jdiner]

On the working directory stuff I was trying to keep things portable and as a free of millions of "#ifdef _WIN32" as I could. So I use the getcwd command.

It is support as is by the GCC compiler for linux versions etc...

--jdiner

[Pendragn]

On the working directory stuff I was trying to keep things portable and as a free of millions of "#ifdef _WIN32" as I could. So I use the getcwd command.

It is support as is by the GCC compiler for linux versions etc...

--jdiner
That's good enough. As long as it's known behavior, I'm good with it.

Malfunct:
Thanks for your explanation, both times. :)

tk

[FredThompson]

How about default to Q2 but a way to change to Q1? This way all edits will work right, and only people that can see the difference between Q2 and Q1 and know they can use Q1 will change that? I think most people that have the Q1 problem were able to hexedit TyTool to change that to Q2 without problems.Are you seriously advocating a default setting to produce lower quality because some people have problems? Early P4s were known to have bad FPU. It was a huge mess because spreadsheets were giving inconsistent results and the problem was traced to Intel's FPU on the P4. How that affects TyTool's performance, I don't really know. It sure seems a logical root cause because all the problem reports are coming from people with P4 CPUs, aren't they?

[FredThompson]

@Rowan,

If you want a Windows shortcut, make it from a windows explorer window and right-click on tytool. That will set the proper paths which you can see/edit by right-clicking on the shortcut icon. You will see it has a path to the application as well as a path to the directory in which to run the application. That makes shortcuts more portable. Uh...they're pointer to pointers, essentially.

[drnull]

It sure seems a logical root cause because all the problem reports are coming from people with P4 CPUs, aren't they?
No, actually, P3's and P-M's are also having the problem. And mine in particular is a NEW P4, I would sure hope they had that problem fixed by now. As jdiner said, it's probably just some cygwin idiocy.

[FredThompson]

I stand corrected.

(Actually, I'm sitting down. fhfhfhfhfhfbfbfbfbfbffbtbtbtbtbttbtb!!!)

[eastwind]

Are you seriously advocating a default setting to produce lower quality because some people have problems? Early P4s were known to have bad FPU. It was a huge mess because spreadsheets were giving inconsistent results and the problem was traced to Intel's FPU on the P4. How that affects TyTool's performance, I don't really know. It sure seems a logical root cause because all the problem reports are coming from people with P4 CPUs, aren't they?
Was that early P4s or early Pentiums? I seem to remember something about this back in the middle '90s, but that is way before P4s (I think it was the original Pentium or the Pentium Pro).

ew

[malfunct]

That is not true, it is very easy for the program to figure out were it is running from. I do it all the time, here is a small code snipit that show show to get the full path of were the exe is running from, you can then append the inf file name and open it. This would make it so the inf file has to be in the same directory as the exe.


TCHAR fileName[MAX_PATH];
::GetModuleFileName( 0, fileName, MAX_PATH );

// remove program name
while ( strlen( fileName ) && fileName[strlen( fileName ) - 1] != '\\' ) {
fileName[strlen( fileName ) - 1] = '\0';
}

At this point fileName has the complete path and you can just add say "tytool.ini" to the end of the string and you have it.

It doesn't matter as far as tytool is concerned because present behavior won't be changed, but I'm curious, does that API return the working directory or the actual path to the exe?

[Rowan]

It doesn't matter as far as tytool is concerned because present behavior won't be changed, but I'm curious, does that API return the working directory or the actual path to the exe?

It will return the full path (actual path) of the current exe you are running from. That way it does not matter were the exe is in the path you can always find out were it is when it gets started.

[larray]

TyTool supports TMF files much better now. But those are 2 seperate tools.

You can use a tool someone else posted about that was in essence just an untar tool that extracted the data from the file and turned it into 1 single .TY style file. Thus no redownload is needed but more disk space is.

As where it was said:

Check the "What does this mean FAQ" for the entry entitled:

Why can't I FAE edit TMF files? - http://www.tytool.com/TyTemplates/FAQ/what/default.aspx#_-_Why_can't

I believe I made it pretty clear there...

--jdiner

:o - (somewhat sheepish grin) - Ok I get it now:
TMF->TyTool = OK
TMF->TyTool->GOP Editor NOT = OK

Did I get this right? Because the two items I listed earlier were not mutually exclusive. Even without doing FAE in GOPEditor TMF->TyTool->GOP Editor no longer produces a "kosher" MPEG for DVDLab. I'm headed home shortly to test Ty->TyTool->GOP Editor = MPEG->DVDLab. Once again I fully admit that this isn't really your problem, it may be something that I need to take up with Oscar but he isn't really responsive these days to paying customers. It was more of a curiousity about the changes from 9r8 to 9r14 and if there was something "unhinged" or if this was the new & improved & here to stay method. I really do appreciate your work.

I never got to that part of the FAQ because I thought it was all about terminology - I know what TY, TMF, TyTool, GOPEditor, etc were, so I never looked there for what I thougth was a usage issue. Semantics. I now know that what I was trying to do was wrong and that I should have re-read all of the FAQ and not just the 3/4 of it that I thougth applied to me.

Andy

[larray]

On the two issues I had:
1) FAE editing - my fault - TY edits just fine, just like the aforementioned FAQ states.

2) MPEG for use in 3rd party tools. I am still getting the error "The VOB file has an encrypted video stream. The file cannot be demuxed". This is with the first 'Multiplex file(s)' option. The second 'Multiplex (new format) 2'option creates a slew of: 'We need to do some rebuilding here!' statements, therefore I originally didn't even attempt to use it. Now in testing I get the same "error". TMPGEnc can do I simple demux just fine, but it's a pain to do this for every file when the 3rd party tool used to be able to rip the MPEG apart.

Just thougth folks might be interested in my findings. I can work around it or use the older revision, but in case anyone came here looking for an answer as I did, I thought it might be nice to have one.

Thanks again for a really good tool Josh!

Andy

[malfunct]

I never got to that part of the FAQ because I thought it was all about terminology - I know what TY, TMF, TyTool, GOPEditor, etc were, so I never looked there for what I thougth was a usage issue. Semantics. I now know that what I was trying to do was wrong and that I should have re-read all of the FAQ and not just the 3/4 of it that I thougth applied to me.

Andy

I thought about suggesting a better name for that section but I just can't come up with anything.

BTW apologies to all for not having 9r14 updates to faq up yet. I am super slammed at work (worked from 6am this morning and its almost 9pm now heh) so I just haven't had the energy to do more documentation in my free time. Also I managed to delete all my extracted video so (stupid windows) and haven't had the desire to look at tytool lately. Its on my list of things to do unless Fred or one of the others get to it first. Again apologies.

[Homer S]

The old issue with the original Pentium causing errors is discussed in http://www.maa.org/mathland/mathland_5_12.html from 1994. The less old issue with P4's performance, not errors, is discussed in http://www.cdmag.com/articles/031/019/pent4_feature.html from 2000.

It seems to indicate that SSE2 optimized code is the answer.

Pedantic moment over...

Homer Out

Are you seriously advocating a default setting to produce lower quality because some people have problems? Early P4s were known to have bad FPU. It was a huge mess because spreadsheets were giving inconsistent results