Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

タイムタグに関する不具合などを改善 #20

Merged
merged 5 commits into from
Aug 6, 2017

Conversation

esperecyan
Copy link
Contributor

@esperecyan esperecyan commented Jul 27, 2017

逆転したタイムタグに対処

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:25]お[00:05:40]

上のような行があれば、ステータスバーに警告を表示し、[00:05:25] を無視してワイプ表示 (再生時間5.3秒〜5.4秒で えお をワイプ表示) します。

バージョン2.3.0では、該当行でクラッシュしていました。

最終行の行末にタイムタグが無い場合にクラッシュしていたバグを修正

バージョン2.3.0で発生。

同じタイムタグに対応

[00:05:00]あ[00:05:10]いうえ[00:05:10]お[00:05:20]

上のような行の場合、再生時間5.0〜5.1秒は をワイプ表示し、5.1秒の時点で あいうえ までワイプ表示せずに色を変え、5.1〜5.2秒で をワイプ表示します。

バージョン2.3.0では、該当行でクラッシュしていました。

連続したタイムタグに対応

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30][00:07:00]え[00:07:10]お[00:07:20]

上のような行の場合、再生時間5.0〜5.3秒は あいう をワイプ表示し、5.3秒〜7.0秒はワイプ表示を停止し、7.0〜7.2秒で えお をワイプ表示します。

つまり [00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30] [00:07:00]え[00:07:10]お[00:07:20] と似たような表示です。

@jz5
Copy link
Owner

jz5 commented Jul 27, 2017

無効なタイムタグは無視する作り(ないものとして動作する)にするのはどう?

@esperecyan esperecyan force-pushed the feature-fix-some-timetag-issues branch from 5a2402a to 7bac373 Compare July 27, 2017 23:01
@esperecyan
Copy link
Contributor Author

修正してみました。

何度か配信でテストしてみるので、問題が無い場合でもマージはしばらく待ってもらえればと思います。

@jz5
Copy link
Owner

jz5 commented Jul 28, 2017

TryLoadLyrics 内 の最初あたりで
タイムタグを順に抽出して
直前のタイムタグより時間が同じか少ない場合は、そのタイムタグを消した文字列を作って
後の処理に回すことで解決しない?

WipeTextBlock.xaml.vb で間違ったタイムタグの判別処理は不要なはず。

@esperecyan esperecyan force-pushed the feature-fix-some-timetag-issues branch from 7bac373 to 4466b3a Compare July 28, 2017 09:39
@esperecyan
Copy link
Contributor Author

TryLoadLyrics 内で直前のタイムタグより時間が少ないタイムタグを除去するようにしてみました。

時間が同じタイムタグは一応タグの付け方としてあり得なくはないですし、そのタイムタグに沿った表示に特別な処理を入れなくても良いので、特に除去する必要はないかと考えているのですがいかがでしょうか。

@jz5
Copy link
Owner

jz5 commented Jul 28, 2017

同じタイムタグで動作するのであれば削除しないでいいと思います。
WipeTextBlock.xaml.vb は変更なしで解決するかと思いますがどうですか。

@esperecyan
Copy link
Contributor Author

同じタイムタグで動作するのであれば削除しないでいいと思います。

諒解しました。ありがとうございます。

WipeTextBlock.xaml.vb は変更なしで解決するかと思いますがどうですか。

たとえば以下のようなファイルで、 の後ろのタイムタグを補完できないので、かきくけ でワイプ表示が止まるようにしましたが、固定値などで補完するようにした方が良いでしょうか。あと、行末に不正なタイムタグがあった場合、次行の行頭のタイムタグの時間が小さいと補完しづらかったりできなかったりするので、前述の処理に合わせています。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お[00:05:50]
[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ
@TimeRatio=1

@jz5
Copy link
Owner

jz5 commented Jul 28, 2017

最後にタイムタグがない場合は
https://github.com/esperecyan/namatyping/blob/4466b3ae749701a603b8b0440f65d2620c73ec54/NamaTyping/Model/Lyrics.vb#L339
で、次の行の先頭のタイムタグと同じ時間にしていると思います。

@esperecyan
Copy link
Contributor Author

歌詞全体の最終行 (次の行がない行) の場合と、行末が不正なタイムタグだった場合です。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お
[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]
@TimeRatio=1

上のような歌詞ファイルだったら次のように補完されると思います。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お[00:06:00]
[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]
@TimeRatio=1

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お[00:05:50]
[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ
@TimeRatio=1

上のような歌詞ファイルの場合は補完されないので、WipeTextBlock._wipeDurations(4) までしか生成されず、 の後ろの部分に対応する WipeTextBlock._wipeDurations(5) を参照しようとして例外が発生します。


[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お[00:05:39]
[00:05:39]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]
@TimeRatio=1

上のように行末に不正なタグがあった場合は、取り除くと以下のようになると思います。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お
[00:05:39]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]
@TimeRatio=1

単純に補完しようとすると、次の行の先頭のタイムタグが少ない時間だった場合上手くいきません。

@jz5
Copy link
Owner

jz5 commented Jul 28, 2017

不正タイムタグ処理は
https://github.com/esperecyan/namatyping/blob/4466b3ae749701a603b8b0440f65d2620c73ec54/NamaTyping/Model/Lyrics.vb#L335
のあとに入れるイメージです。
単にタイムタグを順番にしらべて、早くなっているものは削除して行の文字列を詰める。

これで今までのコードで対応できます。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お
[00:05:39]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]
@TimeRatio=1

一番最後にタグがないものは一番最後のタグをつけるでどうでしょう

[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ
@TimeRatio=1

@esperecyan
Copy link
Contributor Author

一番最後にタグがないものは一番最後のタグをつけるでどうでしょう

諒解しました。[00:06:00]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ の末尾には [00:06:40] を補完するということですね。


不正タイムタグ処理は
https://github.com/esperecyan/namatyping/blob/4466b3ae749701a603b8b0440f65d2620c73ec54/NamaTyping/Model/Lyrics.vb#L335
のあとに入れるイメージです。

[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お
[00:05:39]か[00:06:10]き[00:06:20]く[00:06:30]け[00:06:40]こ[00:06:50]

行末の補完が現在の処理だと、[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お のような行があって、次行の行頭のタイムタグが [00:05:39] の場合、[00:05:00]あ[00:05:10]い[00:05:20]う[00:05:30]え[00:05:40]お[00:05:39] と補完されたままになってしまいます。

補完する際にタイムタグが逆転しないかチェックすればいいとは思いますが、その場合の補完は、最終行と同じ直前のタイムタグの複製でよろしいでしょうか。

本コミットにより、再生中に該当行の行末時点で jz5@899adae 以降クラッシュしていた問題が修正された。
本コミットにより、再生中に該当行の行末時点で jz5@899adae 以降クラッシュしていた問題が修正された。
https://twitter.com/siroro/status/889866002896310274

また、同一行内における同じ時間のタイムタグを正常に取り扱えず、再生中に該当行の行末時点で jz5@899adae 以降クラッシュしていた問題も修正された。
@esperecyan esperecyan force-pushed the feature-fix-some-timetag-issues branch from 4466b3a to 59d945e Compare July 30, 2017 03:41
@esperecyan
Copy link
Contributor Author

申し訳ございません、通知がなくリアクションに気付きませんでした。

配信テストはまだですが、修正してみました。

@jz5 jz5 merged commit b317647 into jz5:develop Aug 6, 2017
@esperecyan esperecyan deleted the feature-fix-some-timetag-issues branch August 6, 2017 07:38
@esperecyan
Copy link
Contributor Author

配信などでテストを行った際について、これまでどのところ、問題は確認されませんでした。

@jz5
Copy link
Owner

jz5 commented Aug 15, 2017

明日対応します。

@esperecyan
Copy link
Contributor Author

催促のようになってしまい申し訳ございません。ありがとうございます。

#28 はissueなので、更新履歴から外してもらえますでしょうか。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants