Welcome to the Lounge

3-Jun-22 12:28

In the old days of DVDs I had a program for extracting and OCRing subtitles from DVDs. It wasn't very good, and it never handled BluRay disks.

Are there (Windows) programs around doing a decent job of extracting subtitles from BD disks, preferably into SRT format (or at least a format with time stamps)?

Randor 3-Jun-22 12:45

Randor

3-Jun-22 12:45

I think HandBrake[^] can do this.

trønderen4-Jun-22 3:20

4-Jun-22 3:20

Maybe it can, but then it is well hidden. I can't find it!

Randor 4-Jun-22 3:43

Randor

4-Jun-22 3:43

Just create a MKV and the subtitle files will be in the resulting MKV container.

It's a complex program. Maybe it would be better to use something that specializes in just subtitles. Go here:

Subtitle Editors/Converters Free Downloads - VideoHelp[^]

Change the second combo box to "Subtitle Editors/Converters" and press "Search" and there are 71 to choose from.

Good Luck. Smile | :)

trønderen4-Jun-22 7:11

4-Jun-22 7:11

Thanks for the good wishes - but I haven't had that good luck yet Smile | :)

I never thought of creating an MKV to extract an SRT. I tried it, and had an MKV made that certainly includes the subtitle track. I can turn it on and off in an MKV player. But neither MKVToolNix (mkvextract.exe) nor MKVExtractGUI2 seems to find the subtitle track. At least not as something that they are able to extract.

Several of those 71 entries in the "Subtitle Editors/Converters" group talks about 'extraction' in the description, but when you start the program, it insists on opening an existing subtext file, not a BD image / directory for extracting and creating a subtext file. The majority of the 71 tools are for authoring your own subtitle file and having it incorporated into a container (such as MKV) - not the other way around, which is what I am looking for. I am still searching, but it is a rather frustrating experience!

I would certainly be grateful for advice from someone who has actually succeeded in extracting subtitles from BD disks, willing to reveal which tools they used for the task.

Jacquers3-Jun-22 20:02

Jacquers

3-Jun-22 20:02

Might be easier just to search for the subtitles online.

trønderen4-Jun-22 3:40

.NET 6.0 is Slower than .NET Framework In Some String Operations

4-Jun-22 3:40

Of course - but not all movies are blockbusters. They do no come to the subtitle sites. If they do, they sometimes come only in the major languages, not the one(s) you are looking for.

Besides, some movies come in different editions, with added or removed clips. If the file at the subtitle site is ripped from a different edition than your disk, time stamps are messed up after the first added or removed clip. If you BD contains clips not in the subtitle file version, it is more than incorrect time stamps, but rather completely missing subtitles.

And, I have picked up files at subtitle sites that were terrible - obviously published with no proofreading, sometimes in a-z alphabet only, ignoring that the subtitle language uses an extended alphabet (e.g. using æøå).

So I do have a need for subtitle ripping from my own discs, even if I mostly use subtitle sites.

georani3-Jun-22 5:52

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

3-Jun-22 5:52

Some tests to check some functions not tested in link below:

Performance Improvements in .NET 6 - .NET Blog (arrays-strings-spans)

.NET 6.0 is (comparing its performance to .NET Framework 4.8):

• 3x faster on String.Replace operations
• 16x slower on String.IndexOf operations,
• 1.4x faster on String.Substring operations
• The same on String.Remove operations

Copy paste the code below and compile with .NET 6.0 and .NET Framework 4.8 and see by yourself.

//Simple Benchmark test for working with Strings in different versions of .NET Framework

string test = "Lorem Ipsum is simply dummy text" +
    " of the printing and typesetting industry. " +
    "Lorem Ipsum has been the industry's " +
    "standard dummy text ever since the 1500s, " +
    "when an unknown printer took a galley " +
    "of type and scrambled it to make a type specimen book. " +
    "It has survived not only " +
    "five centuries, but also the leap into electronic typesetting," +
    " remaining essentially unchanged." +
    " It was popularised in the 1960s with the release" +
    " of Letraset sheets containing Lorem Ipsum passages," +
    " and more recently with desktop publishing software like " +
    "Aldus PageMaker including versions of Lorem Ipsum.";



System.Diagnostics.Stopwatch K = new System.Diagnostics.Stopwatch();

K.Reset(); K.Start();
for (var v = 1; v <= 10000000; v++)
{
    test = test.Replace("a", "bla bla bla bla");
    test = test.Replace("bla bla bla bla", "a");
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for   [String.Replace]: {K.Elapsed.TotalSeconds} sec");

K.Reset(); K.Start();
for (var v = 1; v <= 1000000; v++)
{
    int i = test.IndexOf("including versions of Lorem Ipsum");
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for   [String.IndexOf]: {K.Elapsed.TotalSeconds} sec");

K.Reset(); K.Start();
for (var v = 1; v <= 600000000; v++)
{
    var s = test.Substring(25, 50);
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for [String.SubString]: {K.Elapsed.TotalSeconds} sec");

K.Reset(); K.Start();
for (var v = 1; v <= 90000000; v++)
{
    var s = test.Remove(45, 60);
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for    [String.Remove]: {K.Elapsed.TotalSeconds} sec");

System.Console.WriteLine("Press a key to exit...");
System.Console.ReadKey();

PIEBALDconsult3-Jun-22 6:12

PIEBALDconsult

3-Jun-22 6:12

I don't have .net 6 available.

Might be better not to use a StopWatch for those tests.
Is it a debug build?
How long are those tests taking? Do they take "long enough" for a proper test?

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

0x01AA3-Jun-22 9:42

0x01AA

3-Jun-22 9:42

for (var v = 1; v <= 1000000; v++)

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

PIEBALDconsult3-Jun-22 9:58

PIEBALDconsult

3-Jun-22 9:58

Yes, so how long does it take?

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

georani3-Jun-22 11:50

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

3-Jun-22 11:50

PIEBALDconsult wrote:
Yes, so how long does it take?

Computer: Intel Core I5
.NET 6.0:

Elapsed Time for   [String.Replace]: 17.1540338 sec
Elapsed Time for   [String.IndexOf]: 32.473905 sec
Elapsed Time for [String.SubString]: 11.9497695 sec
Elapsed Time for    [String.Remove]: 9.2207969 sec

.NET 4.8

Elapsed Time for   [String.Replace]: 47.532167 sec
Elapsed Time for   [String.IndexOf]: 2.3447133 sec
Elapsed Time for [String.SubString]: 12.1748157 sec
Elapsed Time for    [String.Remove]: 11.4768551 sec

modified 4-Jun-22 11:46am.

Randor 3-Jun-22 12:06

Randor

3-Jun-22 12:06

Hi,

Can you run the String.IndexOf benchmark again using StringComparison.Ordinal and post the result?

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

georani8-Jun-22 4:03

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

8-Jun-22 4:03

Randor wrote:
Can you run the String.IndexOf benchmark again using StringComparison.Ordinal and post the result?

Thanks, it is the solution:

Now .NET 6.0 is 2X times FASTER than .NET Framework 4.8

Starting tests for .NET Framework 3.5, wait...
Elapsed Time for   [String.Replace]: 51,0830947 sec
Elapsed Time for   [String.IndexOf]: 0,5451713 sec
Elapsed Time for  [String.Contains]: 0,5424978 sec
Elapsed Time for [String.SubString]: 17,7345287 sec
Elapsed Time for    [String.Remove]: 15,021131 sec

Elapsed Time for         [.NET 3.5]: 84,9272387 sec

Starting tests for .NET Framework 4.8, wait...
Elapsed Time for   [String.Replace]: 53,2363039 sec
Elapsed Time for   [String.IndexOf]: 0,5760411 sec
Elapsed Time for  [String.Contains]: 0,595356 sec
Elapsed Time for [String.SubString]: 14,8117435 sec
Elapsed Time for    [String.Remove]: 11,2053769 sec

Elapsed Time for         [.NET 4.8]: 80,4258634 sec

Starting tests for .NET 6.0, wait...
Elapsed Time for   [String.Replace]: 18,5094685 sec
Elapsed Time for   [String.IndexOf]: 0,3495122 sec
Elapsed Time for  [String.Contains]: 0,32621 sec
Elapsed Time for [String.SubString]: 12,1062252 sec
Elapsed Time for    [String.Remove]: 10,1427749 sec

Elapsed Time for         [.NET 6.0]: 41,4367067 sec

Randor 10-Jun-22 6:13

Randor

10-Jun-22 6:13

Yep,

Nobody even noticed my post. Smile | :)

Thanks for running the benchmark, I suspected it would be faster. Smile | :)

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

Pete O'Hanlon3-Jun-22 10:06

Pete O'Hanlon

3-Jun-22 10:06

It's advisable to use a real benchmarking framework when you want to benchmark operations.

Advanced TypeScript Programming Projects

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

georani3-Jun-22 11:38

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

3-Jun-22 11:38

Pete O'Hanlon wrote:
It's advisable to use a real benchmarking framework

Not in this case, StopWatch is sufficient.

JustDre6-Jun-22 6:31

JustDre

6-Jun-22 6:31

georani wrote:
Not in this case, StopWatch is sufficient.

Benchmark.NET makes sure that code is warmed up properly, eliminating simple things like tiered compilation whose defaults may have changed between .NET versions, for example. It also makes it fairly trivial to compare different runtimes: it is, after all, the tool that Microsoft itself uses for comparison of runtimes (to consciously decide when performance regressions are acceptable).

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

pkfox3-Jun-22 11:02

pkfox

3-Jun-22 11:02

Does it really matter in real world applications ? it never has in one's I've been involved in

Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

georani3-Jun-22 11:37

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

3-Jun-22 11:37

pkfox wrote:
Does it really matter in real world applications ?

Yes, my application become unusable after porting it to .NET 6, it uses a lot of string.IndexOf functions.

PIEBALDconsult3-Jun-22 12:29

PIEBALDconsult

3-Jun-22 12:29

Then fix your app.

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

englebart3-Jun-22 15:35

englebart

3-Jun-22 15:35

They probably fixed it make it theoretically faster to find a random string inside another random string which makes it worse for most common usage.

Is it possible that they are creating more objects with the new library to enable simpler garbage collection across multiple/asynchronous threads? There might be different design goals at play.

There was an interesting article I read years ago about some of the algorithms used for string functions in the early BASIC releases.

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

Gerry Schmitz4-Jun-22 4:06

Gerry Schmitz

4-Jun-22 4:06

You didn't / should be using / comparing StringBuilder.

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I

Re: .NET 6.0 is Slower than .NET Framework In Some String Operations

georani4-Jun-22 5:46