TSPE 0.700 Public Beta out now!

[rebkell]

I have another feature addition request :o Would it be possible to increase the time for test edits. Sometimes I have I frames farther apart than your test window time and I really can't see the test edit. It will be just green screen with audio until the test/cut point hits. It would be nice if we could adjust the test edit total time.

The ideal option IMO would be the ability to set the test point time in a variable, like it was in h264ts_cutter.

[Ventolin]

Hi rebkell,

How about the larger of 3 seconds or +/- 2 GOPs? Will add user definable duration later.

Vent

[rebkell]

Hi rebkell,

How about the larger of 3 seconds or +/- 2 GOPs? Will add user definable duration later.

Vent

GOP's would probably be fine, it should assure a good start point, some of the GOPs can be 5 to 10 seconds apart on my videos, as I would figure on a lot. I think x264 has a default of 240 frames. Which depending on FPS could be 10 seconds or so.

[joerg]

Vent: will try to send a sample tomorrow
Well - I got distraced by other stuff and put this aside for a while - sorry for that!
When I wanted to start working on this again now, I noticed that due to the long pause in my tests my trial of TSPE ran out. Currently I am not ready to buy it, so unfortunately I am not able to provide the sample you requested - sorry!

[Ventolin]

Well - I got distraced by other stuff and put this aside for a while - sorry for that!
When I wanted to start working on this again now, I noticed that due to the long pause in my tests my trial of TSPE ran out. Currently I am not ready to buy it, so unfortunately I am not able to provide the sample you requested - sorry!
Hi joerg,

I can send you a temp licence extension if you like, send me a pm if you want one.

The next upcoming version will have timelines, with frame re-ordering so you can now frame step in PTS order.

This should make it easier to understand what is going on.

Regards,

Vent

[joerg]

Hi Vent,

thanks for your very positive reply and kind offer for an extended trial license. Based on this reply and your previous support in this thread I decided to go ahead and buy the software rightaway.

There are two things that made me hesitate buying and I want to let you know about them:
1. I hate hardware-locked software. Not that I'd want to use it on more than one machine, but it keeps me dependent on you if I change my system. While you issue free replacement licenses today, you may decide that replacement licenses will no longer be issued for free at any time you want or you may go out of business. That gives me a pretty bad feeling. I'll have to change my system fundamentally in the next few months (it is more than 4 years old and not capable of playing the HD material that I capture), so I hope getting the replacement license will be painless.
2. I still think the price is a bit high. But your responsiveness and helpfulness on this forum convinced me ;)

I'm looking forward to receiving the license key, which I just purchased.

To keep this at least a bit on topic: Do you have any (approximate) idea when the new version you talked about may be ready? Is it days, weeks or months away? Before posting a sample etc. I'll wait for the new version with frame-stepping in PTS order. Maybe this will already solve all my "problems". Will this new mode also allow me to see which frames I can actually (really) cut at? It would be really helpful if it would allow to a) step through the video looking for possible cut-in-points and b) step through the video looking for possible cut-out-points. I envision two buttons in the PTS-order mode for this: a) jump to next possible cut-in-frame and b) jump to next possible cut-out-frame. This would make exact cutting that much easier and make TSPE the perfect tool (at least for my purposes). With MPEG2 video this was very easy: cut in at I frame, cut-out at I-frame or P-frame. With the HD video formats things got much more complicated. :(

[Ventolin]

Hi Joerg,

Thank you very much for your support!

I'm not a fan of hardware locks either, but I would also hate to see pirate copies readily available especially when people have paid good money. I doubt also TSPE would be where it is today without the support of people such as yourself! Every sale gives a very welcome boost in determination to make TSPE the best I can!

I'm working on the Timelines at the moment, I hope to have that finished by the end of the month. I don't know if I'll add in some of the forthcoming Muxer functions before the next release is available however, but if I did, the timeline would be more useful.

Having a P frame button is a good idea, will see if I can include something like that in the next release or so.

Editing with TSPE should still be as easy as selecting an I frame for the start point and a I or P frame as an end point. "Clean Edits" is supposed to do this! Hopefully with Frame Accuracy it will be even easier.

As for the sample, please do send it to me! I will have a look at the issue you are having and if need be, change the code for the next release.

Regards,

Vent

[Chumbo]

Hi Vent,

Any plans for allowing to save in a different format than being edited? Would be nice to open a .ts file but save as .m2ts or vice versa and so on. Thank you.

[prenz]

@ventolin,

I have problems editing ITVHD streams (sample: http://rapidshare.com/files/233207948/itvhd.ts.html) with TSPE .755

Error: Auto Creating Filter Graph
Beim Aufruf einer COM-Komponente wurde ein HRESULT E_FAIL-Fehler zurückgegeben.
Error Loading Video, Disabling.)

I can't set any start- or endpoints. When I try to save the "edit", it comes up with "Error: PID tree failed validation checks".
I recorded this on an UFS910 with Enigma2. BBCHD and C4HD from the same machine are fine.

[Ventolin]

@ventolin,

I have problems editing ITVHD streams (sample: http://rapidshare.com/files/233207948/itvhd.ts.html) with TSPE .755

I can't set any start- or endpoints. When I try to save the "edit", it comes up with "Error: PID tree failed validation checks".
I recorded this on an UFS910 with Enigma2. BBCHD and C4HD from the same machine are fine.
Hi Prenz,

Thank you very much for your sample!

Your ITVHD sample has no PMT which means TSPE can not correctly identify the streams and will not let you make an edit as all transport streams must have a PAT and a PMT. TSPE should be able to fix this however with it's Table Editor.

However, this is a bad news, good news, good news situation.

The bad news:
There is a bug with the Table Editor which means 0.755 can not fix this by itself. (This is good news really though as I like getting bugs like this as TSPE becomes better once the bug is fixed!)

The good news:
The next upcoming beta has this issue already fixed, though not completely but enough to fix the stream.

The good news 2:
It's possible to fix this with 0.755 with a little help from a working ITVHD cap. All you need to do is copy just the PAT and PMT from the working ITVHD cap to the cap you need to fix.

You can do this 2 ways:
First Way (the hard expert way):
a. Set the start/end packets around the PAT and PMT
b. Add to the EDL.
c. Uncheck Fix Tables and Fix Timecodes
d. Click edit.

(second way joins here)
You should end up with a 1K (2x 188 byte packet) edit.
e. Open this 2 packet .ts file back into TSPE and ignore the warning messages
f. Add to the EDL
g. Load your ITVHD ts file
h. Add to the EDL
i. Make sure Fix Tables and Fix Timecodes is unchecked
j. Click Edit
k. Proceed to Combined Step below

Second Way (Easier Way)
a. Download the pre-edited ITVHD PAT/ PMT file from this URL:
http://www.bitstreamtools.com/download/ITVHD PAT PMT.rar
b. Unrar and save in the same folder as your ITVHD.ts
c. Follow from step e above.

You should now have an edit that should play in a player and give you video preview in TSPE. However, the PIDs still need tidying up.

Combined Steps:
l. Menu->Edit->Table Options -> Table Editor
m. Delete all red entries (missing references in the PAT) if present.
n. Change the order of the H264 and AC3 PIDs by drag/dropping so the AC3 PID comes before the H264 PID. (This is really just to make sure the Table editor's PAT and PMT get used instead of the original PAT/PMT in the stream. You should now have:

PAT PID 0x000
-> PMT PID 0x0D48
--> 0x0D49 H.264 / AVC Video
--> 0x0D4A AC3 Audio

o. Clear the EDL
p. Add to the EDL
q. Click Edit

You should now have a working ITVHD .ts file.

So, we have now used TSPE in Packet Edit mode to fix this issue.

The above is quite complicated and the procedure is quite advanced. I would rate this at 8/10 difficulty.

If this is too much for you, then please be patient until the next beta is ready. You will be able to fix your ITVHD caps by just using the Table Editor.

Hope that helps,

Regards,

Vent

[prenz]

Cheers vent,

The "Hard Expert Way" failed due to the fact I don't have an ITVHD recording with intact PAT and PMT, so I went for the easy way, gone through it step by step and have been left with a 20 MB-file (out of 13 gigs) with no video or audio inside.

So I went for a third option which I would call "the lazy man's way": if the PAT and PMT is missing, why not just prepend ITV PAT PMT.TS right in front of my itvhd.ts - after doing so I could edit my recording without any problems whatsoever. After all, I use TSPE in this case only to edit out the commercials and then demux it right away, which worked beautifully.

So thanks again for being very helpful!

[joerg]

Hi Vent,

I have finally performed more testing and prepared the sample you asked. You can find it at http://rapidshare.com/files/233814814/sample20090517.zip.html. I have added an edl as well as the corresponding .ts file (actually it is an m2ts-file).
As you can see, the edl sets the cut-out at 0:06.70 (an I-Slice).

This is the list of frames around my cut-point (I have numbered them for easier reference):

01. I (0:06.52)
02. I,P,B (0:06.48)
03. I,P,B (0:06.50)
04. I,P (0:06.58)
05. I,P,B (0:06.54)
06. I,P,B (0:06.56)
07. I,P (0:06.64)
08. I,P,B (0:06.60)
09. I,P,B (0:06.62)
10. I (0:06.70) <-- my intended cut-out (last frame I want to see)
11. I,P,B (0:06.66)
12. I,P,B (0:06:68)
13. I (0:06.76)
14. I,P,B (0:06.72)
15. I,P,B (0:06.74)

1) I had to set a preview frame offset adjustment of 3 to get a correct preview. It the problem with my system or TSPE? (This is using CoreAVC). What definitely seems to be a problem with TSPE, however, is the fact that any offset adjustment setting I make is not persistent and re-set once I restart TSPE. Edit: The setting of the "Strip m2ts Extra Headers?" option is also not saved - each time I start TSPE it is not set. The "Save Settings on exit?" option is enabled.

2) If I click the "Jump" button for the End Point the time jumps to 0:06.66 (frame 11) instead of 0:06.70 (frame 10). If I then click "F+" once it stays at that frame/time code. It should obviously jump to 0:06.70 (frame 10) if I hit the "Jump" button.

3) If I cut with the EDL, all frames up to 10. are included in the resulting stream. What I would expect is all frames up to 12. being included (so that the selected frame is the last one being displayed). With the way this is being cut now, the result is that in the timeline frames 11 and 12 are missing. I have to cut at frame 12. explicitly to get a proper result. With further testing I found that apparently for m2ts-files clean edit does not work.

4) The audio in the cut result stops before the video does (i.e. there is a bit of audio missing at the end) - any idea what might be the reason? Is there anything I can do to avoid this? EDIT: I noticed that once I convert the resulting ts to mkv using GDSMux the "missing" audio is there - just when I play the ts it isn't - strange... So it doesn't really look like a problem in TSPE, but if you have any idea why this is I would be interested.

After noticing that the clean cut feature only seems to work with t2 files I converted the whole file to .ts by enabling the "strip m2ts extra headers" option and then cutting again from beginning to end to get a real clean cut. Since the original stream did not start with an I-frame, the timecodes for the frames listed above changed, so here is the list for the second sample, which you can download at http://rapidshare.com/files/233828890/sample20090517_2.zip.html:

01. I (0:06.24)
02. I,P,B (0:06.20)
03. I,P,B (0:06.22)
04. I,P (0:06.30)
05. I,P,B (0:06.26)
06. I,P,B (0:06.28)
07. I,P (0:06.36)
08. I,P,B (0:06.32)
09. I,P,B (0:06.34)
10. I (0:06.42) <-- my intended cut-out (last frame I want to see)
11. I,P,B (0:06.38)
12. I,P,B (0:06:40)
13. I (0:06.48)
14. I,P,B (0:06.44)
15. I,P,B (0:06.46)


5) If I set the cut-out at frame 10, the final frame that is included in the resulting stream is frame 9. The correct cut would be to include all frames till frame 12. If I set the cut-out at frame 11, 12 or 13, the final frame that is included in the resulting stream is frame 12. This seems correct for frames 11 and 12, but if frame 12 is selected, frame 15 should be the final frame that is included.

If the links do no longer work when you read this, please let me know - then I'll send you a new link via PM.

[joerg]

I think found another bug:
If I take an m2ts file, enable "Strip m2ts extra headers" and enable "Fix tables" at the same time, the resulting output file is broken - the video won't play, TSPE reports:

Error: Auto Creating Filter Graph
Error HRESULT E_FAIL has been returned from a call to a COM component.
Error Loading Video, Disabling.
Internal Viewer Closed.

And if I try to open the resulting file in TSPE, it reports:
Opening File...
Unknown File Type, aborting

If I do this in a two-step process (first remove m2ts headers without fixing tables, then load the resulting ts and use "fix tables" everything works fine. But obviously I'd like to avoid that extra step.

You can reproduce that with the first sample package from my last post.

[Ventolin]

Cheers vent,

The "Hard Expert Way" failed due to the fact I don't have an ITVHD recording with intact PAT and PMT, so I went for the easy way, gone through it step by step and have been left with a 20 MB-file (out of 13 gigs) with no video or audio inside.

So I went for a third option which I would call "the lazy man's way": if the PAT and PMT is missing, why not just prepend ITV PAT PMT.TS right in front of my itvhd.ts - after doing so I could edit my recording without any problems whatsoever. After all, I use TSPE in this case only to edit out the commercials and then demux it right away, which worked beautifully.

So thanks again for being very helpful!
Hi Prenz,

Glad to know you have your edit working!

Your Third Option was actually my 2nd option though I guess it was harder to write than it was to do :)

Cheers,

Vent.

[Ventolin]

Hi Joerg,

Thanks for your sample and your tests!

I've had a look at the issues you are seeing. (The numbers below aren't matching with your post)

1. With this sample you do need a preview offset of +3. The preview offset is dependant on the stream though which is why it is not remembered when you restart TSPE. I will have a look at ways to improve this situation.

2. When you set an end point, what you are actually setting the exact point at which to stop the edit. So if you are setting an I frame then everything upto that I frame is inlcuded but not the I frame itself. You would need to set the end point to the next frame in the PTS order.

This I agree is a bit confusing so I will have a look at changing this so the current frame you are looking at is also included.

However, if you do move past the I frame to the next B frame in PTS order, the resulting output is missing the last B frame before the target I frame (in PTS order) which is incorrect. This needs fixing.

3. M2TS vs TS - the sample has shown a few bugs which I need to fix before I can do any further analysis. Thanks for the sample again!

4. Strip M2TS headers with Fix Tables is indeed causing an issue. However, I don't have this issue with my dev build so this bug might already be fixed. I'll investigate further.

5. Jump time inaccuracy - this is a bug that I've known about but haven't got around to fixing yet.

6. Audio - There is an offset between video and audio as you can see from the timestamps of each. In your sample for instance it looks to be about 1.1 seconds. Video arrives in the decoder before the audio as it takes longer to decode the video than the audio. Since the video stream finishes before the audio stream, there are alot of audio packets at the end with no video frames physically in the stream (DTS order as opposed to PTS order). The decoder should output the audio frames, but it seems the decoder stops when the video stream stops as opposed to when the audio stream stops. This results in the audio cutting off before the video. I need to do some more analysis though to confirm this is the case but it looks like this is a design issue in the decoder.

The workaround to this would be to insert blank video frames at the very end of the edit, but it should be OK at an edit point as the next segment will have video first then audio to match.

Still quite a bit of work to do it but I'm working on it!

Thanks for your sample and your analysis :)

Regards,

Vent

[joerg]

Hi Vent,

thanks for your fast reply. I'm glad I could help with the sample. I have a few more questions regarding your reply:


1. With this sample you do need a preview offset of +3. The preview offset is dependant on the stream though which is why it is not remembered when you restart TSPE. I will have a look at ways to improve this situation.

If this is stream-dependent, is there a good and reliable way for me to find the correct offset number?
Also please note that the "strip m2ts extra headers" option is also not remembered.


However, if you do move past the I frame to the next B frame in PTS order, the resulting output is missing the last B frame before the target I frame (in PTS order) which is incorrect. This needs fixing.

I haven't seen that kind of problem. If I set the cut-out at frame 11 from my example and frame-list in my previous post, then frame 12 is also included. So to me it looks correct (unless I'm using m2ts streams).


6. Audio - There is an offset between video and audio as you can see from the timestamps of each.


Thank you for the explanation on the audio issue. Where can I see those timestamps you are referring to? (I can see video timestamps below the preview window, but where do I see the corresponding audio timestamps?).

[Ventolin]

Hi Vent,

If this is stream-dependent, is there a good and reliable way for me to find the correct offset number?
Also please note that the "strip m2ts extra headers" option is also not remembered.
I don't have a good way to do that apart from trial and error. TSPE asks the codecs for the frame and the codecs then displays it. It all depends on how the codecs numbers frames which I don't have access to. One day I'll write my own codecs but that's quite a way off at the moment.

I haven't seen that kind of problem. If I set the cut-out at frame 11 from my example and frame-list in my previous post, then frame 12 is also included. So to me it looks correct (unless I'm using m2ts streams).
I will look further into it, but there is something amiss!

Thank you for the explanation on the audio issue. Where can I see those timestamps you are referring to? (I can see video timestamps below the preview window, but where do I see the corresponding audio timestamps?).
The timestamps are in the Decode Window - look at the PTS times (use the View button to rotate the view to the Packet Decode Window).

I've now made the strip m2ts header remembered :)

Cheers,

Vent

[joerg]

Hi Vent,

I can see the PTS times - but this is for video frames, isn't it? How can I see the times for the audio frames to compare the two and see (calculate) a difference/delay? If I set the "Frame step" mode to audio and step to an audio frame I get something like this:
---------------
PID: 0x184D
Continuity Counter: 0
Attributes: MPEG1 Audio Layer 2, 64Kbit/s @ 44100Hz
Transport Scrambling Control: 0: (no scrambling of TS packet payload)
Adaptation Field Control: 1

MPEG1 Audio Header:
ID: True (MPEG1 Audio ISO/IEC 11172-3)
Layer: 2 (Layer Code: 2)
protection_bit: False (CRC Present)
Bitrate: 64 KBit/s (bitrate_index: 4)
Sampling Frequency: 44100 Hz (sampling_frequency code: 0)
padding_bit: False
private_bit: False
mode: 3: single_channel
mode_extension: 0: subbands 4-31 in intensity_stereo, bound==4
copyright: True
original / home: False (home)
emphasis: 3: CCITT J.17
crc_check: 733A
----------------

...and there is no PTS time displayed. I think there must be something that I do not (yet) understand.

[Ventolin]

Once you have arrived at the first audio packet, click PTS+

This will jump to the first audio PES frame with a PTS. It's then the difference between the Video Frame PTS and audio PES frame PTS.

Just some theory:

Video Frame -> PES frame -> TS Packet
Audio Frame -> PES frame -> TS Packet

PES frame has PTS, DTS, other info, TS Packet has PID, continuity counter, flags, PCR.

Video frames and audio frames can be split over multiple PES frames as necessary.

PES frames are split into many TS packets.

So there are 3 layers:

Elementary streams (Video, Audio, Subtitle, etc)
Packetised Elementary Streams (PES frames, PTS, DTS, etc)
Transport Packets (Continuity Counter, flags, PCR, etc)

All will be alot clearer with the next release as you will be able to see the PES frames in PTS sorted order or in physical order in the transport stream.

Hope that helps,

Regards,

Vent

[joerg]

Hi Vent,

thanks for the explanation - that helped a lot!
Playing around with other caps I made, I found another stream for which the preview doesn't work at all. I ran this stream twice through TSPE to remove the m2ts headers and to fix the tables before starting with the real cutting, so the stream should be clean.
The entire stream is about 105 minutes long. At around 5:22 minutes, the preview window shows the beginning of the movie. But if I cut at this position, the resulting video starts about 9 seconds too early.
To test this some more I cut a segment of the stream from the beginning of the stream till somewhere around 8 minutes. I then loaded this stream and again tried to find the point where the preview window shows the beginning of the movie. This time this was at around 5:29 (instead of 5:22). I made the cut from this position and looked at the result - still about 3 seconds off.

So something with the preview and this stream must be seriously wrong. Do you have any explanation for this? I can't really post a proper sample this time, since that would be much too big to upload for me (the 8 minutes segment is about 450MB in size) - but if there's anything else I can do to help diagnose this, I'd be happy.

[Ventolin]

Hi Vent,

thanks for the explanation - that helped a lot!
Playing around with other caps I made, I found another stream for which the preview doesn't work at all. I ran this stream twice through TSPE to remove the m2ts headers and to fix the tables before starting with the real cutting, so the stream should be clean.
The entire stream is about 105 minutes long. At around 5:22 minutes, the preview window shows the beginning of the movie. But if I cut at this position, the resulting video starts about 9 seconds too early.
To test this some more I cut a segment of the stream from the beginning of the stream till somewhere around 8 minutes. I then loaded this stream and again tried to find the point where the preview window shows the beginning of the movie. This time this was at around 5:29 (instead of 5:22). I made the cut from this position and looked at the result - still about 3 seconds off.

So something with the preview and this stream must be seriously wrong. Do you have any explanation for this? I can't really post a proper sample this time, since that would be much too big to upload for me (the 8 minutes segment is about 450MB in size) - but if there's anything else I can do to help diagnose this, I'd be happy.
Hi Joerg,

The only thing I can suggest is to try and cut the sample size down to something that still shows the issue and then send that to me. When you cut it down, turn off both Fix Tables and Fix Timecodes.

Cheers,

Vent

[joerg]

Hi Vent,

I can't cut it down to something that shows the problem and is still small enough for me to upload. I guess I'll just try to cut it using the "test" option for cut-in and cut-out. I'll keep the original stream so I can re-try with the next version of TSPE.

Update: I finally managed to cut the video, finding the right cut points using the "test" buttons. While trying to find the right cut-point I noticed something very strange. Around my cut-out-point somewhere between 1h20min and 1h30min into the stream, I had a discrepancy between the preview window and the actual cut result of about 4 minutes (i.e. the preview showed a frame 4 minutes ahead of the actual cut point) . I started stepping through the video in 10s steps and very close to my planned cut-out-point the displayed preview video suddenly "jumped" back in time, displaying the correct position in the preview window. Unfortunately (as I said before) I think it is not possible to generate a small enough sample to demonstrate this problem.
Scanning the ts file with TSPE shows no problems at all:

Continuity Errors: 0, Transport Error Indicator Errors: 0
Estimated Continuity Breaks: 0

Update2: The problem exists with CoreAVC and ffdshow as decoder - switching from CoreAVC to ffdshow didn't make any difference.

[Ventolin]

Hi Vent,

I can't cut it down to something that shows the problem and is still small enough for me to upload. I guess I'll just try to cut it using the "test" option for cut-in and cut-out. I'll keep the original stream so I can re-try with the next version of TSPE.

Update: I finally managed to cut the video, finding the right cut points using the "test" buttons. While trying to find the right cut-point I noticed something very strange. Around my cut-out-point somewhere between 1h20min and 1h30min into the stream, I had a discrepancy between the preview window and the actual cut result of about 4 minutes (i.e. the preview showed a frame 4 minutes ahead of the actual cut point) . I started stepping through the video in 10s steps and very close to my planned cut-out-point the displayed preview video suddenly "jumped" back in time, displaying the correct position in the preview window. Unfortunately (as I said before) I think it is not possible to generate a small enough sample to demonstrate this problem.
Scanning the ts file with TSPE shows no problems at all:

Continuity Errors: 0, Transport Error Indicator Errors: 0
Estimated Continuity Breaks: 0

Update2: The problem exists with CoreAVC and ffdshow as decoder - switching from CoreAVC to ffdshow didn't make any difference.

Hi Joerg,

It sounds like Haali is having trouble with the stream then.

The work around is to use Auto-Preview which actually makes a test edit in the background and then displays it in the main Video Window. You loose scrubbing ability as there is a bit of a delay but if you navigate with the buttons or with the keyboard you should be able to get somewhere. The delay would be about a second or two.

To turn on Auto-Preview, Menu-Options -> Timestamp Mode -> Auto-preview.

Hope that helps.

Vent

[rebkell]

Any estimates on when the next revision might come out Vent? No problems with this one, it's working pretty well.

[joerg]

To turn on Auto-Preview, Menu-Options -> Timestamp Mode -> Auto-preview.


Thanks for the hint. I'll try to use that option if I run into such a stream again. I have quickly tested it on a stream. It seemed to work basically ok, but it came back with a black frame instead of the actual frame quite often (I used the I+ and I- buttons to navigate).

One (not really important) request for convenience: Could you make TSPE remember the target directory for edits/cuts (or add an option to do this if not everybody wants this)? Currently it always resets it to the same directory where the source file lies as soon as a new file is loaded.
To improve performance for cutting I have two harddrives, so I can always have different source and target harddrives when doing cuts. I usually have a directory with all source files on one harddrive and put the editing results of all those source files into a fixed target directory on the other drive. So the output directory stays the same for several edits.

I'm looking forward to the next version - being able to cut my m2ts streams in one go will save a lot of time! :)

[Ventolin]

Any estimates on when the next revision might come out Vent? No problems with this one, it's working pretty well.

Hi rebkell,

Still working on the next release, was hoping to have it ready by the end of May but wanted to add in comskip / showanalyzer support. Am adding alot of code for batch processing also, I don't know if batch will be ready for the next release, but the way things are evolving at the moment, it could well be.

Scan and Edit engines will be the same, they will be updated in the release after this.

Major new features of the next version (0.80) will be:
Timelines (yes, there's more than 1!)
Import of different EDLs (comskip / showanalyser / others)
New TSPE EDL format.

Version 0.90 will have hopefully:
Mux Engine (replacing existing Edit Engine)
Timeline enhancements (tied to Mux Engine)
New Scan engine (hopefully)

And for 1.0:
Frame accurate video editing (for MPEG2 / h.264) - VC-1 frame accurate editing to follow.
GUI update

Tentative date for 0.80 end of 2nd Week of June, but don't hold me to that!

Regards,

Vent

[Ventolin]

Hi joerg,
Thanks for the hint. I'll try to use that option if I run into such a stream again. I have quickly tested it on a stream. It seemed to work basically ok, but it came back with a black frame instead of the actual frame quite often (I used the I+ and I- buttons to navigate).
Sorry to hear you are getting black frames with autopreview - it could be that the test size is too small. I still have that to fix!

One (not really important) request for convenience: Could you make TSPE remember the target directory for edits/cuts (or add an option to do this if not everybody wants this)? Currently it always resets it to the same directory where the source file lies as soon as a new file is loaded.
To improve performance for cutting I have two harddrives, so I can always have different source and target harddrives when doing cuts. I usually have a directory with all source files on one harddrive and put the editing results of all those source files into a fixed target directory on the other drive. So the output directory stays the same for several edits.
The new TSPE EDL format will support specifying the output filename but adding in the output folder would need some gui work to be able to offer the option. Not sure I'll be able to add it in for the next release though.

I'm looking forward to the next version - being able to cut my m2ts streams in one go will save a lot of time! :)
Hmmm, I don't know if it would be possible to correct the tables and edit in one operation. The main issue is that the directshow filters will be working on the sourcefile as opposed to the fixed output file which is yet to be created.

Keep bugging me about your issues though! (pun intended!)

Regards,

Vent

[dylmaster]

Hi Vent
I'm a paid up TSPE customer and wondering if you've got any ideas about the widespread problems with lip-sync on ITV HD on Freesat in UK. I record the TS from DVB Viewer and I can watch it back within DVB Viewer with good lip sync. I also get good lip sync with your preview in TSPE. I cannot play it in other players like MP Classic and WMP, or (more important) via ethernet to my network Media Player that feeds the TV in my lounge without a sync error of several seconds! I get the same (bad) results with your (edited) output and also after feeding the TS files through all the TS 'fixer' apps that I have found!
I am wondering if it is simply the rather extreme compression that they are using? BBC HD (also on Freesat) has a similar format but uses more data bandwidth, and gives me no problems with lip sync.
A quick surf of TV forums reveals many many people with all manner of PVR methods all suffering similar problems with recorded ITV HD. To me the crux is that it plays fine within DVBViewer (and TSPE). I have several H.264 decoders loaded.

Go easy on all the nuts and bolts for an old fart!

[Ventolin]

Hi Vent
I'm a paid up TSPE customer and wondering if you've got any ideas about the widespread problems with lip-sync on ITV HD on Freesat in UK. I record the TS from DVB Viewer and I can watch it back within DVB Viewer with good lip sync. I also get good lip sync with your preview in TSPE. I cannot play it in other players like MP Classic and WMP, or (more important) via ethernet to my network Media Player that feeds the TV in my lounge without a sync error of several seconds! I get the same (bad) results with your (edited) output and also after feeding the TS files through all the TS 'fixer' apps that I have found!
I am wondering if it is simply the rather extreme compression that they are using? BBC HD (also on Freesat) has a similar format but uses more data bandwidth, and gives me no problems with lip sync.
A quick surf of TV forums reveals many many people with all manner of PVR methods all suffering similar problems with recorded ITV HD. To me the crux is that it plays fine within DVBViewer (and TSPE). I have several H.264 decoders loaded.

Go easy on all the nuts and bolts for an old fart!
Hi dylmaster,

I don't have a sample long enough of ITVHD to be able to analyse what the issue might be. If there is a way you can upload a sample that is long enough to demonstrate the problem, I will gladly have a look. If not, perhaps you might be able to point me to somewhere that may have some samples large enough? Of course any sample would need to be "untouched" meaning they would have to have the adverts intact if there were any.

Outside of that I can only guess that there are different sync offsets for different segments of the programme. If that were the case, then when the file was edited, the different syncs would add up and give overall desync.

I'm working on making it easier to resync streams, the next version (0.80) will have half the work ready to do this, version 0.90 will hopefully have a new muxing engine which should enable resync of bad streams such as you describe.

In the meantime, does the desync happen when you pass it without making any edits in TSPE (with Fix Timecodes checked)?

Have you tried demuxing and remuxing the source (no edits) with something like TSMuxer?

Do you have desync in PowerDVD 7.3+ ?

I hope you are able to send me a sample that demonstrates the issue so I can work out what's wrong and provide a fix!

Regards,

Vent

[dylmaster]

Here is a very short sequence recorded without any ad breaks but showing all the symtoms previously mentioned:
http://rapidshare.com/files/247042903/06-14_21-22-15_ITV_HD_.ts.html

ITV HD is only broadcasting a few hours a week so chances to record new samples are few and far between!

[Ventolin]

Here is a very short sequence recorded without any ad breaks but showing all the symtoms previously mentioned:
http://rapidshare.com/files/247042903/06-14_21-22-15_ITV_HD_.ts.html

ITV HD is only broadcasting a few hours a week so chances to record new samples are few and far between!

Hi dylmaster,

Thanks for the sample.

I have made a test edit by loading the source and pressing the edit button and then tested the output in TSPE's preview window, MPC with Haali + CoreAVC and also with Haali + FFDShow but found no sync issues with the source or test edit.

Is there something I need to do to be able to reproduce desync other than the above?

Note that in MPC you need to disable the internal splitter by unchecking the MPEG/TS/PVA option, (if you have MPC-HD uncheck the h.264 options as well). This will enable Haali as the splitter.

Also, this sample has long GOPs - 62 fields (interlaced frame) so be sure to set your start points at I frames and note where your P frames are for end points. TSPE should find these automatically, but if you set them manually you have more control over where the edit point will be.

I don't know what networked media player you have and would be hard to help with that anyway as I don't have one at all to test with. If you do have issues with the *source* with the networked media player, I would advise getting in touch with the manufacturer to find out if they can help.

I suspect it may a direct show filter setup that may be causing the desync. Do you get the Haali icon when you play in MPC?

Regards,

Vent

[dylmaster]

OK - doing some more experiments there is obviously quite a complex scenario with my various players (and choice of decoders) on my HTPC. So let us initially concentrate on my Network Media Player (a Buffalo LinkTheater HD).
It turns out that the audio sync problem with ITV HD is fixed if I run the .ts file through tsMuxeR and set it to TSMux. I'm not sure exactly what it does but it fixes the problem! Funnily enough I was already using this technique to cure another problem with BBC HD where the Buffalo wouldn't recognise the AC3 track.
Since I want to edit most recordings, it would be great if TSPE could do whatever tsMuxeR is doing! I could post you some more examples if required.

[Ventolin]

OK - doing some more experiments there is obviously quite a complex scenario with my various players (and choice of decoders) on my HTPC. So let us initially concentrate on my Network Media Player (a Buffalo LinkTheater HD).
It turns out that the audio sync problem with ITV HD is fixed if I run the .ts file through tsMuxeR and set it to TSMux. I'm not sure exactly what it does but it fixes the problem! Funnily enough I was already using this technique to cure another problem with BBC HD where the Buffalo wouldn't recognise the AC3 track.
Since I want to edit most recordings, it would be great if TSPE could do whatever tsMuxeR is doing! I could post you some more examples if required.
HI dylmaster,

Glad to hear you have found a solution!

Hopefully the Muxing Engine will be the major feature of TSPE 0.90 - the next release after the upcoming release (0.80) which is Timelines.

After those will be Frame Accurate which will take us upto 1.0!

Regards,

Vent

[dylmaster]

To put this back into context, If I take a film I've recorded and run it through tsMuxeR, then all is well and I get good sync. If I then edit out the ad breaks with TSPE, it loses sync after the first edit. Running the edited file through tsMuxeR doesn't make any difference. I was careful to only edit on I frames.
I shall look forward to the later versions and keep you in touch with my success (or failure!).
cheers

[rebkell]

To put this back into context, If I take a film I've recorded and run it through tsMuxeR, then all is well and I get good sync. If I then edit out the ad breaks with TSPE, it loses sync after the first edit. Running the edited file through tsMuxeR doesn't make any difference. I was careful to only edit on I frames.
I shall look forward to the later versions and keep you in touch with my success (or failure!).
cheers

eac3to will probably cure the edited file gaps for you. All edits seem to leave small gaps in the audio at the edit points. My players don't mind, since TSPE keeps the timestamps aligned.

But if you try to remux the audio and video after editing it will be out of sync for sure.

If you plan on remuxing after editing or if your player doesn't handle the audio gaps or if you want to convert the edited file to an mkv or something, I'd advise eac3to, it will create an audio and video stream that will sync up and can be muxed back together in your choice of muxers.

[dylmaster]

I'm doing nothing other than cut editing on I frames. It jumps out of sync by about a second after the first edit!.
I'll try eac3to when I get a chance (just off to work).

[dylmaster]

eac3to seems to be an audio decoder. My problem is that the recorded TS files don't seem to have the audio and video properly 'connected' for my Network Media Player (or for several computer based players). There is clearly more than one way to do this since DVBViewer and TSPE both play the recorded files fine. Running the file through tsMuxeR somehow adds the required 'connection' (and corrects the header info so that my N.M.P. recognises the AC3 track). This is rather mysterious since tsMuxeR is nominally muxing a file that is already muxed! Editing this new file in TSPE loses the connection at the cut point.
Now I am sure that this has something to do with timecode and timestamps (whatever they are) but if somebody could explain what is going on to an old fart in language I can understand, then I'd be very grateful!

[Ventolin]

Hi dylmaster,

Both Video and Audio have a PTS - Presentation Time Stamp. This is the key factor in ensuring sync. Every Video frame should have a PTS but there can be many audio frames with 1 PTS.

A decoder's responsibility is to make sure a Video Frame is displayed at the same time as the corresponding audio frame is output.

Things would be easy if the decoder could decode 1 video frame and 1 audio frame and output them then move to the next frame. However, video is compressed using data from multiple frames. This means a group of frames (or pictures aka GOPs) are needed before the decoder can decode those frames and display them.

So a decoder has a buffer where it stores frames until enough frames are available to decode them and display them at the right time. Audio also has a buffer so the decoder's job now is to decode both the video and audio and store them in a buffer large enough to be able to display the video in sync with the audio.

Now consider if alot of frames are required before the decoder can display the first one - the audio needs a big enough buffer in the decoder so that the buffer doesn't fill up while waiting for the video to become ready. To help this situation somewhat, the audio is generally sent out of sync (offset) with the video - eg. a Video frame may arrive into the decoder with a PTS of 10.0 seconds followed by an audio frame with a PTS of 9.5 seconds.

The trouble comes when there are edits - the Presentation Timestamps (PTS) needs to be re-written so both audio and video remain in sync after the edit point. However, this can be tricky especially if the sync between different segments of the program changes. Furthermore, not all audio frames have PTS associated with them so the decoder may not be able to output audio until a PTS is received.

So here are a few explanations as to why you have desync:

1. The Decoder is not honouring the PTS of the Video and Audio for whatever reason.

2. The Audio sync is changing inbetween advert breaks and the decoder has too many or not enough audio frames so looses sync.

3. The PTS restamping is going wrong.

4. Something else is going on.

Without having a larger sample, I can't give you a precise answer as to what the exact issue is. I suspect it is option 1 though.

Remuxing or passing a transport stream through a muxer like TSMuxer basically repackages and restamps the video and audio. This can help the decoder honour the PTS of Video and Audio but it doesn't change the sync offset between the two. So if you cure desync by just remuxing, the Decoder you have is having a tough time honouring the timestamps. This really is a limitation of the Decoder in this case.

If remuxing does not cure the issue then something else is wrong and would need further analysis.

You can follow what is happening in your stream by looking at the PTS of both the Video and Audio and working out the difference between them. Use I frames as a reference point then move to the next audio frame by selecting "Frame Step - Audio" then using the F+ button and then use the PTS+ button to move to the next audio PTS.

I hope that clears a few things up a bit!

Regards,

Vent

[dylmaster]

Vent - that is very clear, thanks very much for that explanation.

It does prompt some obvious questions -
1) does TSPE have it's own H.264 decoder or does it use one of those already in the system?
2) does TSPE change the PTS after an edit, or is this what you mean by remuxing?

I have noticed whilst editing in TSPE that as I step through the video by repeatedly pressing the I+ button (next I frame) that the video doesn't always progress forwards on the timecode count. Indeed it is obvious by inspection that it is sometimes going back. It also sometimes gets the interlace reversed when playing at normal speed. Usually this is fixed by pausing and restarting. Any thoughts as to what these effects would be caused by?

thanks for your understanding and great support.

[dylmaster]

Actually - thinking on - it occurs to me that this particular programme is a film and therefore (in PAL land) is 'progressive'. The effect I sometimes see on the TSPE monitor window therefore cannot be a reversed interlace but is an actual incorrect playing order for the decoded frames.
FWIW

[Ventolin]

Vent - that is very clear, thanks very much for that explanation.
Hi dylmaster, glad it's helped!

It does prompt some obvious questions -
1) does TSPE have it's own H.264 decoder or does it use one of those already in the system?
2) does TSPE change the PTS after an edit, or is this what you mean by remuxing?
TSPE has partial decoders for all the codecs. For video preivew however, it uses the direct show filters already installed in your system. You can use a custom direct show filter chain however under the Options menu (Enable Direct Show Control and specify the filters under Direct Show Control).

TSPE restamps the PTS (and the DTS and PCR) by default when you make an edit. You can turn this off by unchecking the "Fix Timecodes" option next to the Edit button.

Some more theory:

There are 4 layers at work here:

1. Acutal Video Frames or Audio Frames
2. Elementary Stream Layer (Video & Audio etc)
3. PES Layer (Packetised Elementary Stream layer which holds the PTS timinig information). PSI (programme specific Information also comes here which contains the PAT and PMT (tables which say what streams make up a programme (PMT) and what programmes are contained in the stream (PAT)
4. Transport Stream Layer (which holds the PCR timing information)

Imagine each layer as a wrapper - starting with layer 1 being your actual content, layer 2 really sticks a bunch of Audio frames together into an Audio Frame (Video already is a frame but can be split into 2 fields). Layer 3 contains the magic PTS (and DTS) sync info and adds another wrapper and finally Layer 4 makes 188 byte or 192 byte "chunks" of all of the above layers which is the basic unit of a Transport stream and thus the basic unit of TSPE.

When you remux you unwrap all the layers back to the acutal Video and Audio frames (layer 2) and regenerate layer 3 and layer 4 by using the existing layer 3 and layer 4 as a base.

More to follow...

Vent

[Ventolin]

I have noticed whilst editing in TSPE that as I step through the video by repeatedly pressing the I+ button (next I frame) that the video doesn't always progress forwards on the timecode count. Indeed it is obvious by inspection that it is sometimes going back. It also sometimes gets the interlace reversed when playing at normal speed. Usually this is fixed by pausing and restarting. Any thoughts as to what these effects would be caused by?
This is more than likely a Direct Show filter issue but can be allieviated somewhat by experimenting with Direct Show Filter Control.

Note that as frames are stored out of order in the stream, when you Frame step (F+) you will notice the timecodes jump forwards and backwards depending on the type of frame but the Byte Position and Packet Count still go upwards. This is by design as you are navigating at the Transport Packet Layer (4) and not the 1st layer (1).

Now PAL and interlaced and movies:

Most movies are shot on Film and are called Progressive.
Most TV shows are shot on cameras and are called Interlaced (or Video).

In the days of old when CRT TVs were the norm, everything was broadcast as Interlaced. Since CRT TVs are interlaced by design everything matched together so you didn't notice.

Now with Flatscreens and High Definition etc. the Display end is mostly Progressive.

So for Film you have:

Film (progressive source) -> interlaced for broadcast -> Deinterlaced for Display
Video (interlaced source) -> interlaced for broadcast -> Deinterlaced for Display.

Now because in both situations you have an interlaced broadcast format, both Progressive frames and Video Interlaced frames are split into fields. This is where problems start.

Too often you have broadcasters inserting Logos or DOGs all over their content for channel branding (but will tell you its so you know what channel you are watching forgetting about EPGs etc). This can cause issues because the Logos can be pure interlaced. Add an interlaced logo to a progressive source means you now have Interlaced content which needs to be deinterlaced correctly to give you Progressive frames.

It's because of issues like this that sometimes the 2 fields that make up a progressive frame can get swapped or a field can get lost so a 1 frame is made up of 2 fields from different frames.

Now the Deinterlacer in your display needs to work out what fields go where when they are in the right order or when they are in the wrong order. Working out the correct order when things go wrong is down to the quality of the Deinterlacer you have.

A quality Deinterlacer will work out where the fields are and put them back in the right place. A less expensive deinterlacer might not check at all and just display each field as they arrive.

What's worse is that if the logo is interlaced you now have a pure interlaced source (the logo) which can not be made progressive in an exact way (like you can with progressive frames). So you end up with that horizontal "combing" effect you sometimes see.

Imaging what is required to convert a pure interlaced source into a progressive frame. In this case there are varied solutions ranging from making each field a frame (field interpolation) to scene analysis to work out which parts are moving (apply field interpolation) and which parts are static (weave both fields together only for the static areas).

You can quickly see that deinterlacing is a HUGE subject and I have just scratched the surface.

I hope that helps clear some more things up for you (and others) but I know all of this stuff is pretty technical!

thanks for your understanding and great support.

You are welcome!

Just in case you didn't know, there is some info on the Bitstreamtools Website (http://www.bitstreamtools.com) about all this, but I still have plenty more information to add there! I should be cutting and pasting from here to there and vice-versa!

Regards,

Vent

[dylmaster]

Just in case you didn't know, there is some info on the Bitstreamtools Website (http://www.bitstreamtools.com) about all this, but I still have plenty more information to add there! I should be cutting and pasting from here to there and vice-versa!
Vent

Great idea - this is all gold dust to my mind!

I have now purchased the CoreAVC codec and it has made a big difference to the sync in MPC. I also have most of the usual (free) suspects but my previous (trial) of CoreAVC had expired so I'm not sure what I was actually using. I'm going to systematically work through all the options (that's a lot!) and set everything correctly. That may well need some more education (there are lots of 'how to' web postings out there!) so I may well be some time!

[dylmaster]

Note that as frames are stored out of order in the stream, when you Frame step (F+) you will notice the timecodes jump forwards and backwards depending on the type of frame but the Byte Position and Packet Count still go upwards. This is by design as you are navigating at the Transport Packet Layer (4) and not the 1st layer (1).
Vent

Ah yes, I had forgotten this. So in order to make an edit in TSPE with least effect on the sync, how would I actually choose the points? Clearly I should always start a wanted clip on an I frame, but how do I finish it on the last frame in the GOP? I had been going to the nearest I frame (from my desired out point) and then stepping back one frame, but this ignores the jumbled frame ordering in the GOP (or does it, now I'm confused!).

[Ventolin]

Ah yes, I had forgotten this. So in order to make an edit in TSPE with least effect on the sync, how would I actually choose the points? Clearly I should always start a wanted clip on an I frame, but how do I finish it on the last frame in the GOP? I had been going to the nearest I frame (from my desired out point) and then stepping back one frame, but this ignores the jumbled frame ordering in the GOP (or does it, now I'm confused!).
Hi dylmaster,

CoreAVC works very well indeed with TSPE, better than FFDShow, but the latest FFDShow displays to P frame accuracy so is also useful.

Start points should be I frames, end points can be I or P frames. The "Clean Edits" option works out where the nearest I or P frames are for both start and end points and removes any unwanted B frames at the edit points. I would always advise setting the start/end points manually and then testing each edit point by selecting two rows in the EDL, right clicking and choosing Test Edit Point.

Next version with timelines will make this alot easier!

Most of the options in TSPE are really there to disable some part of the AI in case there is an issue with it. As time goes on though, TSPE is becomming more robust and so the options aren't really needed anymore.

Regards,

Vent

[joerg]

Tentative date for 0.80 end of 2nd Week of June, but don't hold me to that!

I'm sorry if I seem impatient, but I can't keep myself from asking: any news about that release, which was originally planned for May (IIRC) and then 2nd week of June?
I have been holding off editing most of my HD caps, hoping it will get easier with the new version of TSPE with fixed bugs and the timelines functionality.
Of course I know that it's hard to predict a release date, especially if an application is developed in one's limited spare time.

[Ventolin]

I'm sorry if I seem impatient, but I can't keep myself from asking: any news about that release, which was originally planned for May (IIRC) and then 2nd week of June?
I have been holding off editing most of my HD caps, hoping it will get easier with the new version of TSPE with fixed bugs and the timelines functionality.
Of course I know that it's hard to predict a release date, especially if an application is developed in one's limited spare time.

Hi guys,

Sorry I have not posted earler, I am very busy with quite a few things! (IRL, not related to TSPE).

Next version is still "almost ready" the bulk of the code is working but needs some refinement. I also have a big bug to fix which is proving to be quite tricky to resolve.

Comskip / Showanalyser import ability is already coded and working, the timelines also are working but are not so pretty and not too useful at the moment, but defintely is an improvement over the text based EDL.

TSPE will be heading towards full multi-track editing but this will be ready for 0.90, with 1.0 having frame accurate editing.

Hope that helps, please do keep checking here for the latest news and the website.

Regards,

Vent

[JonRead]

Hey Ventolin, sorry to ask as I know you are probably busy, but any news on how things are progressing now to the next beta ?

[Ventolin]

Hey Ventolin, sorry to ask as I know you are probably busy, but any news on how things are progressing now to the next beta ?

Hi,

Yeah, been very busy lately, here's what's left to do:

0.80:
Misc updates and bug fixes - done
Internal Demux engine - done
Comskip / showanalyser EDL import - done
Timelines (stage 1) - done
Bug1 in output - working on
Bug2 in output - todo
Tidyup & polish - todo

Once I get those 2 bugs sorted, just needs a little bit of polish and 0.80 be ready.

The 2 bugs are big ones though and are taking alot of time trying to fix.

After that will be:
0.90 - Muxing engine, timelines stage 2
1.00 - Frame accurate

2 versions will be available - Professional and Standard (limited analysis), the betas at the moment are all for Professional.

Sorry for the continued delay folks, but I hope you will enjoy the upcoming features!

Regards,

Vent

[NotAScooby]

Vent,
First off, congratulations on creating a tool (TSPE) that succeeds where many, many commercial packages fail. For the task of quickly editing an HD TS stream while keeping sound and video in sync, I've yet to find anything close, let alone better.

I've been trialling your current test version 0.755, have read this entire thread and many other references while I've been doing my trial, and I'm ready to purchase it from you, but there is one big concern stopping me:

Since your release of 0.755 in March you've been very busy with other things and your posts to this thread have been very few. This worries me, as there are clearly bugs in 0.755 and missing features that you've been promising for coming releases since June. So, I have to ask myself, is 0.755 stable and useable enough for me to buy it at the current price if, in the worst case, your development has stopped and there are not going to be any more releases?

Sadly, my answer to that is no.

The main bugs that are causing me problems are:

- If I open a recorded HD stream (say BBC HD), and do a simple edit (Set a start point, set an end point, click the edit button) the written file is created perfectly. If I then change the name of the 'save' file and move the slider, or delete the EDL entry to cut a different section, the program usually fails with a microsoft 'TS packet editor has encountered a problem and will close' error (usually something like Appver0.755.3526.31214 modname quartz.dll offset 000d0d7e). This is annoying rather than critical, and there's an easy work-around by simply re-opening the file, but I often need to split one recording into several parts so it's something I've hit a lot.

- when moving around in a file using the jump buttons, I often hit a memory exception 'this memory area cannot be written', and again the program is closed. This is more annoying as it's unpredictable and unreproducable and often happens after I've added several sets of edits to the EDL.

- If I try to use the > and < buttons or IF+/IF- to select an edit point, then most of the time the image displayed does not change, so I am 'in the dark' about where the cut point is being set.

- More often than not, the popup test window has no sound, or fails to open. I realise that this is probably a problem with the configuration of my sound / video drivers, and I haven’t spent much time trying to resolve it.

There are other problems, but these are the ones giving me most grief at the moment. Similarly, there are lots of things that I would like to ask you to add, but these are 'nice to have' rather than essential to the operation of the software. Now, I can understand from what I've read on this thread that all my problems are probably due to my configuration or the setup of my Filters, but if I cannot rely on the rapid response to teething problems that you were giving earlier in the year, then I'll be 'on my own' and without any source code or detailed documentation I'll be struggling with trial and error, and I'm not prepared to spend tens of euros to be left in that position.

I've installed the latest haali splitter (which made a huge improvement), and followed your other advice in this thread, but am left with the worrying suspicion that your development has stopped, and 0.755 is as far as this software is going to go. With no expectation of any additional functionality, or of any bugs being fixed, TSPE is not as appealing as it was.

To stop at 0.755 would be a loss for everyone who has supported you to date, and the many people like me who are ready to support you in the future, but I realise that life moves on and none of us can predict what other demands there will be on our time, or what other opportunities come knocking.

So, to quote your reply in message 104 when you were asked "If author goes out of business can I move licence", you said "It'll be "Acts of God" that will take the authors "out of business" and even then I'm sure TSPE will still live on!". I must ask - has there been an "act of god"? are you still "in business"? because if not then with a hardware locked key; if your development work is ended, then this software would become useless next time I upgrade my PC, and that's a real limit that I think will stop anyone from purchasing.

I hope you can come back with some reassurance, I really would like to have a copy of TSPE, fully supported with a planned upgrade schedule, and I would be happy to pay your asking price to be in that position. I can imagine how many hundreds of hours you have already invested in this development, and I would much rather pay you than try to start a similar development from scratch. I can only see the demand for your software growing with the proliferation of Media PCs, so I am sure your potential market is increasing rather than decreasing, but if development must stop, so be it.

I hope you're still checking this thread, and hope to hear from you.

Regards,

Dave