I wish there was an option to skip reading punctuation marks.

[1353604736]

I hope there can be an option to skip punctuation marks when reading aloud, so that the reading speed can keep up with the subtitle display speed as much as possible when the video is played at 2x speed.

音声読み上げの際に句読点をスキップできるオプションがあればいいと思います。そうすれば、動画を2倍速で再生したときに、できるだけ字幕の表示速度に読み上げ速度が追いつけると思います。

[limura]

Well, that is an interesting opinion.

As a test, I added the following to the first line of AddSpeechQueue() and tried it in a Japanese environment.

text = text.replace(/[、。]] /g, " ");

I don't think this test gave me the results I was hoping for.

The results may vary depending on the language and the text-to-speech engine used, so we cannot conclude that this result is meaningless, but it did not seem to be very meaningful, at least as far as we were able to test it at hand.

Also, in Japanese, punctuation is "、。" but in English it is ",." is a punctuation mark. I wonder if ";" and ":" are also relevant in English. I am not familiar with English at all, so I don't know. I am not familiar with English, so I don't know. So, it seems to me that we need to think of a way to allow the user to specify what constitutes punctuation.

In this case, it would be better to consider how to present the setting to the user. In the above example, "、" and "。" to eliminate /[、。]] /g" to eliminate the "、" and "。", but it is not a good idea to show this regular expression to the user as it is. I think it would be more "understandable" to show it in the form of an ON/OFF toggle button with a sentence like "Ignore punctuation marks and read the text out loud". The drop-down point is part of the content of the regular expression, specifically "、。" In that case, what kind of explanatory text would make it easier for the user to understand the operation? If possible, I would like to avoid sentences that could be misunderstood.

In summary, I have the following concerns What do you think about these?

1. removing punctuation does not shorten the time of speech much (2) We need to specify punctuation in various languages, but what kind of UserInterface should be the option item to specify the punctuation?

なるほど面白そうな意見です。

試しに AddSpeechQueue() の最初の行に以下のようなものを追加して、日本語環境で試してみました。

text = text.replace(/[、。]/g, " ");

このテストでは、あまり期待したような結果にはなっていないように思います。

恐らく、言語や利用する音声合成エンジンによって結果は異なると思われるのでこの結果をもって無意味だとは断定できませんが、少なくとも手元で試した範囲ではあまり意味はなさそうでした。

また、日本語では句読点は「、。」ですが、英語では ",." が句読点だと思います。英語においては ";" や ":" も関係するのでしょうか。私は英語には全く詳しくないのでわかりません。その他の言語となると私には全くわかりません。そうしますと、句読点に当たるものをユーザが指定できるようにするといったような方法を考える必要がありそうです。

この場合、ユーザにどのようにその設定を見せるかを考えたほうが良さそうです。上記の例では「、」と「。」を排除するために /[、。]/g という正規表現を使っていますが、この正規表現をそのままユーザに見せるのは良くないと思われます。私はどちらかというと、「句読点を無視して読み上げるようにする」といった感じの文章で ON/OFF のトグルボタンといったような形で見せるのがより「わかりやすい」ものになると思っています。落とし所としては正規表現の中身の一部、具体的には「、。」の部分だけを見せるのが良いかとは思いますが、その場合はどのような説明文を入れるとユーザとして動作がわかりやすいでしょうか。勘違いするような文章はできれば避けたいです。

纏めますと、以下のような点に懸念を感じています。 これらについては如何に考えますか？

1. 句読点を消してもあまり発話時の時間は短くならない
2. 様々な言語での句読点の指定をする必要があるが、その指定をするオプション項目はどのような UserInterface になると良いか

[1353604736]

I don’t understand the logic of the code very well, but I wonder if you can add a switch option to control whether to ignore the punctuation pauses when reading the subtitles aloud.

But I guess the code seems to use the FetchCaptionData() function to store the fetched subtitle data in json.

Use regular expressions to replace the punctuation marks in the original subtitle content, and overwrite the original json, so that tts reads the replaced json subtitle file or content. This way it can be universal for punctuation pause problems in various languages.text = text.replace(/\p{Punctuation}/gu, " ");

Some languages’ TTS do have pauses when reading subtitles with many punctuation marks, such as Chinese TTS. For subtitles with multiple punctuation marks, this option still has the effect of speeding up the reading.

[limura]

I see what you mean about p{Punctuation} possibly being useful. However, p{Punctuation} has a fairly wide range of applicability, so it would be quite wild to uniformly rewrite those characters as whitespace characters. I am concerned because I simply don't know about p{Punctuation}. It is a fear of not knowing that I don't know what happens when a character that falls under p{Punctuation} is blanked out in an unknown language. However, it would be possible to define an option in the form of a "switch option", i.e., an ON/OFF switch, if you want to use the p{Punctuation} format. In that sense, it is promising. Therefore, I would like some evidence that changing p{Punctuation} to blank would be ok. Can you indicate?

Also, I wasn't sure how fast it would be in Chinese. Is it possible to indicate this with a numerical value? As I mentioned before, I don't think, at least I don't think, that implementing this feature would have much effect. If you are not convinced of this issue, you will not move from me.

Secondly, and this is not related to the main topic, but about the subtitles being in JSON. The subtitle data we use in CaptionSpeaker is JSON as the original data, so we take that and convert it to an internal format and use it. In that sense, the internal format is in the form of a JavaScript dictionary or array; you might call it JSON, but it would be more correct to understand it as simply the internal format of JavaScript.

p{Punctuation} が使えるかもしれないという話はなるほどです。しかし、p{Punctuation} は適用範囲がかなり広いのでそれらの文字を一律で空白文字に書き換えてしまうというのはかなり乱暴なのではないでしょうか。私は p{Punctuation} について単純に知らないので心配です。未知の言語で p{Punctuation} に当たる文字が空白になった時にどのような作用をするのかがわからないという、知らないことによる恐怖心です。 なお、p{Punctuation} を利用する形式で良いのであれば "switch option" つまり ON/OFF スイッチの形式でオプションを定義することは可能でしょう。そのような意味では有望です。そのため、p{Punctuation} を空白に変える事で大丈夫であるという根拠が欲しいです。示すことはできますか？

また、中国語の場合はどの程度早くなるかよくわかりませんでした。数値で示すことはできますか？ 前にも書きました通り、少なくとも私は、この機能を実装したとしてもあまり効果は無いと考えています。この問題を納得できない場合は私から動くことはありません。

次に、これは本題と関係ない話ですが、字幕をJSONにしているという話について。 CaptionSpeaker で使っている字幕のデータは、元のデータがJSONなので、それを取り込んで内部形式に変換して使っています。 そのような意味では内部形式は JavaScript の 辞書 や 配列 といった形式になっています。JSONと言っても良いかもしれませんが、単に JavaScript の内部形式であると理解したほうが正しそうです。

[limura]

なお、句読点を端折る事で読み上げの時間を短くするよりは、意味を要約するなどして発話する単語自体を減らす方が有効な気もしています。 この場合は例えば大規模言語モデル等を使って要約をさせると良さそうですが、Youtube動画を開くたびに大規模言語モデルに要約をさせていると時間がかかるであるとか、課金周りをどうするかといった問題が解決できそうにありませんね。そのような意味ではあまり有望ではないアイディアになりそうです。

[limura]

特に新しい情報もないようなのでcloseします。