After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565339 - Easily visualize subtitle errors
Easily visualize subtitle errors
Status: RESOLVED DUPLICATE of bug 439832
Product: gnome-subtitles
Classification: Other
Component: general
0.7.2
Other All
: Normal enhancement
: ---
Assigned To: Maintainers of GNOME subtitles
Maintainers of GNOME subtitles
Depends on:
Blocks:
 
 
Reported: 2008-12-22 13:04 UTC by Daniel
Modified: 2010-11-07 13:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel 2008-12-22 13:04:20 UTC
Never allow negative durations, always compensate the "to" time to at least match the "from" time - unless there is a reason to use negative durations that I do not know of?

Other information:
Comment 1 Pedro Castro 2008-12-25 14:01:23 UTC
It's true that subtitles, in a valid state, shouldn't have negative durations. However, while editing their times, the duration might become negative. Consider a subtitle starting at 5s and ending at 8s. The user runs the video and detects the end time at 4s. He then goes and change that time, after which he goes for the start time, which was at 1,5s.

On the meanwhile, the duration was negative. If that duration couldn't be set negative, the user would have to know/be obliged to change the start time first, and then go for the end time.

I think this shouldn't be necessary. On the other hand, we're considering implementing an error detection mechanism which could also be used here. If a subtitle had errors, it would be shown red and displayed in the error list. That said, while the subtitle had a negative duration it would be shown with an error.

Of course, if you can point me to an application that has your behavior, I can give it a try.
Comment 2 Daniel 2008-12-28 11:51:04 UTC
Ok,

If there is a reason - I accept it.

This could be a behavior toggled by the user; menu option with a check-mark in front of it, but this is not something I feel is absolutely essential.

Cheers
/ Daniel
Comment 3 Daniel 2008-12-28 12:17:07 UTC
(In reply to comment #2)
> Ok,
> 
> If there is a reason - I accept it.
> 
> This could be a behavior toggled by the user; menu option with a check-mark in
> front of it, but this is not something I feel is absolutely essential.
> 
> Cheers
> / Daniel
> 

Sorry - not used to Bugzilla yet... Seems like I pushed this and some others to UNCONFIRMED... :(

I vow to never ever use the "Additional comments" field again :)

/ Daniel
Comment 4 Pedro Castro 2008-12-30 14:33:49 UTC
No problem. I'm updating the title to better reflect the need for errors in subtitles (including negative duration) to be easily visualized.
Comment 5 LoLDog 2009-11-04 02:38:27 UTC
If there was a way to just define the beginning of the dialog and automagicaly calculate the space between the end and the beginning of the next subtitle that would be great :)

Like this:

Minimum time space between subtitles = 500ms

So if you have a subtitle the begins in 00:00:30,500 --> 00:00:33,500 and the next one is 00:00:33,700 --> 00:00:34,000 the program would change the spacing of the first one to 00:00:30,500 --> 00:00:33,200.

This way you just have to update the beginning that should always start at the right time and never move. Well I don't know anybody that pushes subtitles after someone spoke something but there could be some special cases I'm not sure.

I think what I want to say is that one only needs to fix the end point not the beginning automatically.
Comment 6 LoLDog 2009-11-08 20:38:51 UTC
http://home.gna.org/gaupol/screenshots.html

Gaupol is the one I use to correct subtitles it have a lot of correcting features(not shown on the screenshots) maybe it could serve as a base.
Comment 7 Pedro Castro 2010-11-07 13:03:39 UTC
Marking as a duplicate of "Dialog with information, errors and error correction" which should include error correction features.

Comments on this bug should be taken into account while developing the dialog.

*** This bug has been marked as a duplicate of bug 439832 ***