【開発】 TS関連ソフトウェア総合スレ Part14

1 ： ◆0X7hT.k8kU ：2014/09/01(月) 23:23:24.79 ID:als2P50Z.net

専用スレが立っていないTS周り諸々のソフトウェアについて語りましょう

過去スレ
【開発】PT1 Friio HDUS bon系 TS関連ｿﾌﾄｳｪｱ総合ｽﾚ (Part1)
http://pc11.2ch.net/test/read.cgi/avi/1230739003/
【開発】 TS関連ソフトウェア総合スレ Part2
http://pc11.2ch.net/test/read.cgi/avi/1235667096/
【開発】 TS関連ソフトウェア総合スレ Part3
http://pc11.2ch.net/test/read.cgi/avi/1240726004/
【開発】 TS関連ソフトウェア総合スレ Part4
http://pc11.2ch.net/test/read.cgi/avi/1246099246/
【開発】 TS関連ソフトウェア総合スレ Part5
http://pc11.2ch.net/test/read.cgi/avi/1252674823/
【開発】 TS関連ソフトウェア総合スレ Part6
http://pc11.2ch.net/test/read.cgi/avi/1259061990/
【開発】 TS関連ソフトウェア総合スレ Part7
http://pc11.2ch.net/test/read.cgi/avi/1269400568/
【開発】 TS関連ソフトウェア総合スレ Part8
http://hibari.2ch.net/test/read.cgi/avi/1279108411/
【開発】 TS関連ソフトウェア総合スレ Part9
http://hibari.2ch.net/test/read.cgi/avi/1314275425/
【開発】 TS関連ソフトウェア総合スレ Part10
http://toro.2ch.net/test/read.cgi/avi/1323049561/
【開発】 TS関連ソフトウェア総合スレ Part11
http://toro.2ch.net/test/read.cgi/avi/1341073328/
【開発】 TS関連ソフトウェア総合スレ Part12
http://toro.2ch.net/test/read.cgi/avi/1358933709/
【開発】 TS関連ソフトウェア総合スレ Part13
http://peace.2ch.net/test/read.cgi/avi/1388848508/

489 ：名無しさん＠編集中：2014/10/26(日) 11:28:29.10 ID:ykTG5IqH.net

>>487
２０年以上も前のシステムなのに、駅によっては古いシステムのままなんよ
MOに丸ごと環境とか保存してあるから、引っ張り出して作業するわけで
修正報告書だって下手にフォーマット弄れないし、開発ルームは骨董品ばっかだよ

490 ：名無しさん＠編集中：2014/10/26(日) 11:30:24.35 ID:OyoGhmf6.net

鉄道なんかだと(レール越しのだったかな？)通信速度がめっちゃ遅くて通信データをでかくできないとかあったような
それに安全性重視のところだと、なかなか新しい規格は入れにくいってのもあると思う

491 ：名無しさん＠編集中：2014/10/26(日) 11:40:11.10 ID:4hdMBZfE.net

外部仕様はともかく中核ロジックが全て数百MBになろうかという1個のライブラリに入ってて
リンクに毎回1時間というあのビルド環境だけはどうかしてると思った
まああれは慣習というより開発体制の問題だから、同じ業界でもどこでもああじゃないんだろうけど…

492 ：名無しさん＠編集中：2014/10/26(日) 11:54:05.19 ID:ov1Y5ta2.net

COBOLにまつわる話はまだわかるんだ
金の問題だから
でもTV受像機の規格とか捨てるタイミングあっただろうに

そんな体質を変えられないからまさかのTV事業丸ごと
半ば捨てないといけなくなるんだｗ

493 ：名無しさん＠編集中：2014/10/26(日) 13:24:25.90 ID:TZ18jLi9.net

新しいスタンダード採用しとけよつっても、規格策定時に、求めてる機能がその新しいスタンダードの環境で
整ってなかったなら、結局そこを独自拡張する事になるわけで

そもそも特に困っていないのなら、既に正しく機能しているものを無理に変える必要は無いのは常識だし、
実績あるものを選ぶのはむしろ当たり前だろう
インフラ系(放送はこれに含まれるだろう)では特にね
アジャイル最高みたいな業界とは重視されるものが根本的に違うよ

494 ：名無しさん＠編集中：2014/10/26(日) 13:26:24.53 ID:TZ18jLi9.net

ついでに言うと、Unicodeの概念は理想的ではあるんだけど、各国からこれこれの文字が欲しいと言われる状況が
ずっと続いてて、もうこれで良いだろて状況にはなかなかなりそうにないよ
最近でも顔文字に黒人用が無いのは差別じゃねーかなんて話があったし

495 ：名無しさん＠編集中：2014/10/26(日) 13:28:55.90 ID:TKuujlhI.net

なんでH.264を採用してなかったんだとか言うアホもいるからなあ。

496 ：名無しさん＠編集中：2014/10/26(日) 13:32:47.28 ID:ov1Y5ta2.net

H264はタイミング的に無理だな
PSPが先行的にハードウェアデコード採用して程度の過渡期のものだったし
でも文字は可能だったよ・・・

497 ：名無しさん＠編集中：2014/10/26(日) 16:15:04.97 ID:TZ18jLi9.net

ホントにARIB STD-B24ちゃんと読んだ？
どう考えても既存の符号化方式使って満たせる要件じゃないと思うんだけど…
例えば文字サイズとか色指定を符号化できなきゃダメだけど、それを表現できるスタンダードな符号化方式なんて
現時点でもちょっと思い当たらない(し、マークアップ言語がこれだけ普及してる現状を考えると、今後も出ないと思う)

で拡張が必要になるわけだけど、例えばUnicode使ってUTF-8拡張で実現しようとするよりは、どう考えても
ISO-2022-JP拡張する方がスジは良いわけで
それぞれの符号化方式の構造を考えると、ここに異論を挟む余地は無いでしょ

498 ：名無しさん＠編集中：2014/10/26(日) 16:23:57.61 ID:TZ18jLi9.net

とここまで書いて思ったんだけど、ID:ov1Y5ta2は文字集合と符号化方式をゴッチャにしてるような気がする
”文字の並びそのものはS-JISに近い”発言なんかはそのせいなんじゃないかね
どうも批判してる部分はISO/IEC 2022由来の部分に見えるし、規格を批判できるほど詳しい人には見えないかな…

それに、ISO-2022-JPは田舎の方言どころか電子メールではほぼ標準でしょ
メーラーのデフォルト設定なんて大抵そうなってると思うよ
まあこれに関してこそ、現在では技術/規格的には問題無く変えられるけど、環境的に変え難い例だとは思うけど

499 ：名無しさん＠編集中：2014/10/26(日) 16:46:01.17 ID:BXsSXvV1.net

>>498
めんどくせーしUTF8でええやんと思いマフ。

500 ：名無しさん＠編集中：2014/10/26(日) 17:04:17.81 ID:HRHOUats.net

unicodeも改版繰り返してて、PCならともかく、家電が追従するのは少々難しい気が

501 ：名無しさん＠編集中：2014/10/26(日) 17:51:04.06 ID:ov1Y5ta2.net

アスキーコードの後半が空いてるからって勝手に半角かな入れて
キャラクターコードとかいっちゃう国なんだし
s-jisベースで空いてるところ使えばいいだけやん

502 ：名無しさん＠編集中：2014/10/26(日) 18:17:41.29 ID:4hdMBZfE.net

JISの難儀な所は面倒臭いマシンステートを持っている所だよ
半角を扱わない分にはまだ何とかなるが、それを越える現状の要求で更にそのマシンステートを
拡張する方向で仕様を決めたもんだからコードも保守も非常に厄介になる
一度でもARIBテキストを扱うコードを組んだ人なら誰でも知っている事
ま○ももこの件に関してはくたばれARIBって前に言ってただろｗ

はっきり言えばテキストとスタイルを混在で符号化という思想がもう近代的ではないんだよ
それはHTMLも辿った歴史だし、ラインプリンタが漢字INや漢字OUTを扱っていた頃から
この特性は分かりきっていた事、しがらみや経緯で今の符号化を採用する事はあっても
合理的な理由で採用する理由なんかねえよｗ 現場で作業せず机上の理論だけこねくり回してればいい人は色々言うけどな

503 ：名無しさん＠編集中：2014/10/26(日) 18:24:01.41 ID:ov1Y5ta2.net

1バイト単位でけちってた昔ならまだ譲るがもうそういう時代じゃねえしなあ・・・
ほんといまだにこのコード体系を採用したのは理解できん

504 ：名無しさん＠編集中：2014/10/26(日) 18:26:15.38 ID:VTirgD+Z.net

で、結局どうすんの？
一人一人が対処するしか方法ないん？

505 ：名無しさん＠編集中：2014/10/26(日) 18:40:19.70 ID:OyoGhmf6.net

>>503
放送データは１バイトをけちるくらいでちょうどいいのかも
ワンセグとかまで考えると

506 ：名無しさん＠編集中：2014/10/26(日) 18:45:13.40 ID:4hdMBZfE.net

>>504
今EPG絡みでARIBテキストを処理したいのならソースが公開されている範囲だと
個人的には仕様書＋TvTestかEDCBのコードを参考に実装する事を勧めるかな
静的なデータでなくチューナーからの入力を直接扱うならリカバリに強いTvTestの実装か

ただしEDCBに関しては定数と静的配列はかなり参考になると思うけどコードの流用は
あまりオススメ出来ない
EPGを単独で扱うツールは他にもあったと思うのでそちらを当たる手もある
後は自分の整えてる開発体制に対して調査コストと独自に実装するコスト、やりたい事を
天秤にかけて何に傾くかで個人個人が判断するしかないかと

507 ：名無しさん＠編集中：2014/10/26(日) 18:49:14.89 ID:yhR+D3hh.net

枯れた技術に拘ってた、NASAの悪口はそこまでだ
新技術取り入れたインドがさっさと火星にたどりついちゃったんだから

ま、似たようなのはどこの国でもある
最先端突っ走ってる国でもコボラー技術者の需要は０にならないんだから

508 ：名無しさん＠編集中：2014/10/26(日) 18:54:28.28 ID:ov1Y5ta2.net

>>506
妥協してTvtestの管理してるEpgDataを読むことにした
日本の嫌なところをSTD B24で見てしまって興味がうせた

スキルもないがそんなのは興味があれば割とどうにでもなる

509 ：名無しさん＠編集中：2014/10/26(日) 19:03:43.44 ID:TZ18jLi9.net

>>499
メールの話なら、個人的には俺もそう思う
でも現実問題、過去には確かに8ビット流せないMTAなんてのも実在してたし、
普通の人はそれ程困ってもいないだろうから(むしろ普通の人はhtmlメールかも)、
なかなか変わる事は無いんじゃないかね

規格レベルではメールヘッダに直接UTF-8を許可しようぜってのまで決まってて、漢字メールアドレスとかも
大丈夫になってるらしいんだけど、こっちは正直普及しないでコケると思うｗ(つーか、コケて欲しくもある)
ちょっと前にgmailが対応宣言してたけど…

>>501,502
> s-jisベースで空いてるところ使えばいいだけやん

だからそれじゃどう考えても求められてる要件は満たせないでしょ、と説明したつもりだったんだけど
批判したいならせめて機能要件くらい把握した上でどうぞ…

510 ：名無しさん＠編集中：2014/10/26(日) 19:08:29.19 ID:TZ18jLi9.net

>>502
> JISの難儀な所は面倒臭いマシンステートを持っている所だよ

要は、ISO/IEC 2022由来の部分だよね
スタンダードスタンダード言う割には、ISO規格由来の部分をガラパゴスだのJAPって感じだの
叩いてるのが違和感あるんだよなー

> はっきり言えばテキストとスタイルを混在で符号化という思想がもう近代的ではないんだよ

これに関しては全く持って同意

>>504
別に、自前実装しなきゃいけない人でもない限り特に何かをする必要は無いでしょ
既にこの辺りを扱うライブラリは幾つかあるんだし
義務じゃないけど自前でつくりたいって人はつくれば良いけど、めんどくさいよってだけ

511 ：名無しさん＠編集中：2014/10/26(日) 19:13:58.12 ID:ov1Y5ta2.net

でもmpeg2 systemの仕様の範囲ではEITは決めてなくて
ARIB独自の実装でもいいんでしょ？

ISOの決めた範囲はPAT,CAT,PMT,NITでNITは存在だけ決まってて実装は
ARIBで決めていい範囲だし

512 ：名無しさん＠編集中：2014/10/26(日) 19:20:00.27 ID:/SYt8Kdk.net

なんかわけわからん長文ばっかだな
tvmaidはどうなったん？進展した？

513 ：名無しさん＠編集中：2014/10/26(日) 19:22:18.83 ID:ov1Y5ta2.net

ロートルの置き土産についての話だからねえ

電機が仕切るとこういう糞が産まれるんだよな

514 ：名無しさん＠編集中：2014/10/26(日) 19:33:38.88 ID:NreR9vyx.net

>>509
あなたの説明じゃ専門的すぎて通じないと思うよｗ

>>503
>>481 の
＞映像に比べれば番組表の文字なんてs-jisだろうがそうそう
＞増えたことにならねえしなあ
を読んだときから思ってたが、なんか勘違いしてない？
SJIS こそ、その１バイト単位でケチるための発想だよ。
>>501
＞s-jisベースで空いてるところ使えばいいだけやん
だから、使える文字数は少なく、余裕なんてない。
足りなくなったら特殊な拡張をするしかないが、
そうなったら SJIS のメリットはほぼなくなる。

>>502
まるもが言ってたのは、半角全角の扱い等拡張の仕方がとんでもなことについてで、
ベースが JIS なのとは直接関係ないかと。
まあ、言いたいことはわかる。過去との互換性もバイト数を気にしなくていいなら、
文字コードは３２ビット固定の独自コードにでもして、
字幕の色やらなんやらは別データってあたりにすれば扱い易いだろうね。

515 ：名無しさん＠編集中：2014/10/26(日) 19:35:48.80 ID:ov1Y5ta2.net

番組情報はPID 0x12,0x26,0x27のEITにある
これはISOが決めるのではなくARIB

地デジの仕様を決めるころすでにwindowsはあったはず
なのになぜアナログ時代のポンコツ文字規格を採用したのか

516 ：名無しさん＠編集中：2014/10/26(日) 19:55:44.14 ID:TKuujlhI.net

文字コードなんてテレビ・レコーダー実装の全体からしたら埃くらいの手間のだと思うんだがな。
これくらいでぶーたれてたら、全体実装になると絶望するだけだろｗ

517 ：名無しさん＠編集中：2014/10/26(日) 20:00:54.87 ID:ov1Y5ta2.net

tsパケットも結局はmpeg2 psで使うようなデータを
tsパケットにリパッケージしてるだけだしなあ
tsパケットからesパケットを見つけてmpeg2デコーダーなんかに投げる

518 ：名無しさん＠編集中：2014/10/26(日) 20:09:53.44 ID:4N3OStx7.net

STD-B24的にはUnicodeを使った符号化も規定されてたよね。
TR-B14で運用的にはISO-2022ベースのしか使わないように制限されてるけど。

519 ：名無しさん＠編集中：2014/10/26(日) 20:21:06.83 ID:4hdMBZfE.net

>>514
ARIBで半角(厳密には特定スタイルのフォント)と全角(同じく)の切替に
マシンステートの実装を要求する事とJISコードの体系は無関係じゃないんだよ
そもそもANSI/半角と全角を混在で扱おうとした時の漢字INと漢字OUTのあまりの
扱いの面倒さに何とかステートレス(完全ではないが)なコード体系を、
という需要に基づいて生み出されたのがSJISだった位だからな

まあこれはこれでトレイルバイトがUnix体系と激しく衝突して今度はEUCを生み出し、
NT系のWindows日本語版辺りから徐々にUTF-16が浸透し、今はUTF-8に流れて
本当にここで落ち着くのか未だに懐疑的な部分はあったりするけどな…
それでも文字処理においてステートを持たせる事が面倒を招く事は昔から議論の余地のない所で、
その意味でJISコードは本質的に全角のみを処理する体系にしか向かない事は否定のしようがないぞ

コードとしての唯一のメリットは最も多くの区を扱えるので豊富な外字をサポート出来る事だが、
他のデメリットが大きすぎて政治的な事情以外では大体歓迎されないコードになってしまっている

520 ：名無しさん＠編集中：2014/10/26(日) 20:25:25.05 ID:svhKDkBb.net

今日はやけにどっかのサイトから拝借してきたような長文がうじゃうじゃだなｗ

521 ：名無しさん＠編集中：2014/10/26(日) 20:40:29.76 ID:qLZHfcYc.net

老害が悪い

522 ：名無しさん＠編集中：2014/10/26(日) 20:53:37.41 ID:4hdMBZfE.net

>>514
それともう一つ

＞SJIS こそ、その１バイト単位でケチるための発想だよ

間違いとは言わないが圧縮よりもステートレスの方が需要としては遥かに大きかったはず

今のARIBコードも含めてJISコードの体系は(半角混じりで扱おうとすると)途端に
文字単位のランダムアクセスが困難になり、文節の区切りからシーケンシャルにしか
処理出来ないという点が昔から疎まれてた
ぶっちゃけJISコードよりは遥かにマシだがSJISやEUCもこの弱点は抱えていて、
それ故に第１・第２までを扱う上ではUTF-16が歓迎された風潮もあった位

ARIBではもう開き直って半角を全角のフォント変形、カタカナとひらがなを別ステートの
同一文字として扱っているので本来ならこの弱点を逆手に取って半角・全角、カタカナ・ひらがなを
区別なく無コストで一括検索出来るというメリットもあったりするはずなんだが、
とりあえずEDCB等では有効活用されておらずただ面倒なコードとしてしか処理されていない

せめて家電等の内部実装では有効活用されてるといいんだがな・・・

523 ：名無しさん＠編集中：2014/10/26(日) 21:26:38.80 ID:NreR9vyx.net

>>519
ああ、スマン。そのへんのことはわかってる。
だから「“直接”関係ない」と書いた。
SJIS 推しの人がいるが、余裕がなくステートを使わない拡張は相当苦しいので、
どうせとんでも拡張されただろうから大差なかったんじゃないかなと。
UTF ベースならまあ可能だけど、
「半角コードも全角コードも全角で表示し、半角を使いたい場合は〜」
なんて平気でやる連中にまともなコード体系が作れたかどうかｗ

>>522
そこは、SJIS のほうが大きくなると勘違いしている彼への説明なので……。

＞ぶっちゃけJISコードよりは遥かにマシだがSJISやEUCもこの弱点は抱えていて、
EUC は最上位ビット見れば判別つくけど、
SJIS はそれも無理だからその点では JIS と大差ないかも。

524 ：名無しさん＠編集中：2014/10/26(日) 21:38:00.89 ID:ptF+MbMN.net

なんていうか、どうでもいいや

525 ：名無しさん＠編集中：2014/10/26(日) 21:46:52.04 ID:4hdMBZfE.net

＞SJIS はそれも無理だからその点では JIS と大差ない

流石にこれだけはないから
SJISはANSIコードを１バイトでも読み出せば次が文字の頭(ANSIかリードバイト)で
ある事は判明するが、JISでは制御コードを一切混ぜず全角のみを扱う規約でなければ
非常に困難、もちろんARIBでも不可能

526 ：名無しさん＠編集中：2014/10/26(日) 21:54:57.74 ID:TZ18jLi9.net

全くの新規開発なら単なる文字情報扱うのにステートマシンなんて持ちたくないってのはわかるし、
ISO-2022-JP自体が扱いにくい符号化方式だってのもその通りだとは思うけど、
ISO-2022-JPの実装なんてB24の仕様策定時点でも既にありふれてて十分枯れてたし、
それを拡張してスタイル情報を表現できるようにするのと、例えばUTF-8みたいなステートレスな符号化方式
使った上でスタイル情報はXML/XSLに任せる(ただし新たにそれらのパーサが必要になる)のと、どっちが楽か？
て話だったんじゃないかね

言ってみれば、Unicode + その私用領域 + UTF-8 + XML + XSLのかわりをB24単体で受け持ってるんだから、
扱いが面倒になるのはある意味しょうがないかと
でも、PCでの録画ソフトみたいに基本的に欲しいのは文字情報だけな場合には、ただの扱いにくい文字列だなと
感じるのは事実だけどｗ

527 ：名無しさん＠編集中：2014/10/26(日) 21:56:04.07 ID:BXsSXvV1.net

>>518
みんなそんなの対応してるのかな？

528 ：名無しさん＠編集中：2014/10/26(日) 21:59:30.50 ID:qLZHfcYc.net

>>527
紳士規定に過ぎない物だけどお上の決めることだから
逆らわないで従うのが日本流
特に国内大手や国内の放送局がかかわってると

だから糞糞とレスが並ぶ

529 ：名無しさん＠編集中：2014/10/26(日) 21:59:35.08 ID:TZ18jLi9.net

ともあれ、今更あれこれ愚痴っても何にも変わらんのだし、必要な状況では粛々とARIB文字列扱うようにすれば良いだけかと

530 ：名無しさん＠編集中：2014/10/26(日) 22:02:23.41 ID:qLZHfcYc.net

ところでTvtestのEPGで管理してるUpdateTimeって基準はなんなんだろう
数字的には2chのdatを決めるのに似てるけど2chの時間よりずれてるんだよな・・・
別のものかな？

531 ：名無しさん＠編集中：2014/10/26(日) 22:02:34.64 ID:TZ18jLi9.net

>>528
何の話してるのかわからないのなら無理に絡まない方が良いよ

532 ：名無しさん＠編集中：2014/10/26(日) 22:05:31.11 ID:4hdMBZfE.net

>>526
昔はCPUの都合もあった
今と違ってレジスタ帯域の狭いCPUも広く普及していたので(Z80とかな)、
管理ステートが発生するとそれだけ余計にレジスタを占有して低速なメモリへの依存が高まり、
それだけで速度の低下を招いた、まあCPU自体の速度もメモリ速度も遅かったからな

そういう意味じゃ今の方がまだJISには有利な環境と言えるんだが、実情はまあ何というか…

533 ：名無しさん＠編集中：2014/10/26(日) 22:16:48.89 ID:NreR9vyx.net

>>525
あんたもつまらん突っ込みするの好きだね。
だから、「同じ」ではなく「大差ない」と書いたでしょ。あと、「かも」を勝手に削るな。

自分も、糞真面目に先頭からパースしなくても、何バイトか遡るだけで判別できるなと
１６ビット時代にはそういうコードを書いたこともあるが、
今度は先頭をオーバーしないように工夫しないとならず、
パイプラインベースで条件分岐命令を極力排除したい現在どうなんだか。
文字を大量に扱うエディタ等では、予めフラグを作るなり
１文字が固定長になるよう変換しといたりしないと、いずれにせよ非効率だし、
そういう意味で自分的には大差ないという認識なだけ。

534 ：名無しさん＠編集中：2014/10/26(日) 22:27:21.17 ID:4hdMBZfE.net

>>533
かもという表現が使えるほど曖昧な差ではない、という認識だから言ったまでだがね
少なくとも知らない人が見たら明らかに誤解を招く内容を指摘されてつまらん突っ込みと
返すあんたも相当だよ

CPUのアーキテクチャ云々を言う前に検索一つとってもJISだと単純なバイトサーチが
かけられない現実がある訳だが、その辺が大差ないと本気で思ってるのか？

ぶっちゃけその意味じゃARIBコードをJISコードより評価していたりもする
ただ制御コードを別枠にしなかった事でせっかくの設計がほぼ機能しない事になってしまったが

535 ：名無しさん＠編集中：2014/10/26(日) 22:52:57.81 ID:NreR9vyx.net

>>534
だから、>>522 のランダムアクセスが困難うんぬんについて、
「その点では〜」と書いただけなのに、勝手に拡大解釈しないでくれ。
文字列編集を筆頭に、ステートが面倒なことくらい、
ある程度理解してる人ならみんなわかってるだろ。

突っ込みついでに検索について言うと、
誤爆する可能性が多々ある点で、
SJIS も単純なバイトサーチはできないというべき。

SJIS は、ダメ文字問題もそうだけど、
なんとなくそのままにできそうで実は完全じゃないことが多く、
対策を後手後手にしてしまった（どころか現在も解決してないこと多し）という点で、
今となっては害も多かったと言わざるを得ないところもあるんじゃないかな？

536 ：名無しさん＠編集中：2014/10/26(日) 23:13:33.68 ID:4hdMBZfE.net

多々と言うにはかなり語弊があるな
まずANSI文字の連続、つまり2文字以上のANSI単語の検索に関しては1字1字が明確に
ユニークな体系のサーチと比べて効率は殆ど低下しない
(いちいち理屈は説明しないぞ)
次に全角混じりのトークンに冒頭文字についても誤爆を一切招かないケースは多い
(リードバイトとトレイルバイトでは定義域が違う為)
対する半角/全角混在のJISコードはどうか？言わなくても分かるよな

基本的にJISコードの体系ってのはCRやLFと同じ、ラインプリンタの都合を
大きく考慮して作られたコード体系だというのが正確な理解だと思うがね
だからあれは漢字INや漢字OUTを含めて文字コードというより出力コマンドだと理解すると分かりやすい
CRやLFその他の制御コードと同様、歴史的にはもちろん意味のある事だが、
メモリ上に置いて種々の処理を行うのに都合がいいようには元々作られていない訳で、
その辺りが他のコードより不利でも当然の話で何の恥でもないと思ってる

ただその延長線上で混在コードの仕様を定めちまったら
色々歪な現象を生むわなってだけの話が何故それ程受け入れられないのか

537 ：名無しさん＠編集中：2014/10/26(日) 23:13:35.52 ID:/SYt8Kdk.net

いつまで続けんのこれ
後はメアド交換してやってほしいんだけど

538 ：名無しさん＠編集中：2014/10/26(日) 23:24:05.42 ID:A3jc8Z2b.net

単に細かいことをつつき合ってるだけで主義主張を受け入れるとか受け入れられないとかの話は一切してないなｗ

539 ：名無しさん＠編集中：2014/10/26(日) 23:28:41.43 ID:NreR9vyx.net

>>537
都合の悪い突っ込みは無視し、
本質に関係ない解説ステートに入ってしまうようなのでもうやめるよ。

文字列パースより会話文のパースについて考えて欲しいなあ。

540 ：名無しさん＠編集中：2014/10/26(日) 23:39:13.91 ID:4hdMBZfE.net

5を90と言ったり10を100と言ったりするような詐欺師の手法に対して突っ込んでるだけなんだがね
まあ風向きが悪いから止めたいというなら構わんよ
とりあえず知らない人が聞いたら誤解を招くような偏った主張は控えたらってのが趣旨だから、
そちらが自分の中でどう折り合いをつけるかとかは割とどうでも良かったりする

541 ：名無しさん＠編集中：2014/10/26(日) 23:43:40.84 ID:/C8N7xKX.net

上で色々と議論されてるけど、この文字コードの仕様考えた人は変態だよね。
決して悪い意味だけでの変態というわけではないけどｗ
こういう何でもかんでも一カ所に詰め込んでしまえという設計も場合によってはアリと思う。
別にこのやり方がベストだとは決して思わないけど、もう実際に運用されていて、どうやっても
変わりの無いようなものについてああだこうだいってもね…（っていっちゃうのは野暮かｗ）

文字コードに表示する場所とか表示色指定の情報も入っていたり、半角的なものを表示したかったら
幅を半分にすればいいじゃんみたいなダイナミックな考えも嫌いじゃない。
実際に運用されている字幕のデータでも、カタカナだけではなく他のものも半分にしてるよね。

542 ：名無しさん＠編集中：2014/10/26(日) 23:57:32.19 ID:4hdMBZfE.net

ARIBコードも結局はコマンドの体系だから、定められた仕様通りに動作する(表示する)だけの
実装を書く分にはむしろやりやすいって面はあると思う
次からはこのスタイルのフォントだ、この文字だ、この色だ、このシフトだって感じで、
単純にバイトとステートに応じたパーサを書くだけで済むからある意味何も考えなくていい
ただこのコード体系ではコードがクライアントでこっちがサーバ的な関係を強制されている

だから定められた仕様以外の目的で使おうとすると途端に面倒が噴出する
今のJISコードをベースにした体系でも文字列とそれ以外の情報を別枠に分離しておくだけで
あらゆる処理のコストが全然違うんだけど、表示の効率に特化した仕様になってるって理解

543 ：名無しさん＠編集中：2014/10/26(日) 23:59:15.35 ID:NreR9vyx.net

やめると言ったが、流石に詐欺師呼ばわりされてはなあ。
「これは汚れてるので半額にするよ」と言ったら、
ほかのも勝手に汚され、
「半額だって言ってたのにそうならなかった。詐欺だっ！」
と言われた気分ｗ

544 ：名無しさん＠編集中：2014/10/27(月) 00:06:24.34 ID:HCDAYsqg.net

ああいえば、上祐？

545 ：名無しさん＠編集中：2014/10/27(月) 00:08:06.98 ID:wtp+InL6.net

わざとやってるんだろうけど
あまり長文垂れ流してると512KB制限に触れて1000を越える前にDAT落ちするぞ？

546 ：名無しさん＠編集中：2014/10/27(月) 00:14:06.58 ID:6QkU1/kv.net

続けてもいいけどその話するときはコテハンにしてくれ
NGしとくから

547 ：名無しさん＠編集中：2014/10/27(月) 00:16:06.35 ID:lSHAzr8x.net

みな8単位符号には悩まされてきたトラウマがあるから燃えるんだよきっと・・・

548 ：名無しさん＠編集中：2014/10/27(月) 00:18:40.91 ID:Jr+fjA7x.net

死にたい

549 ：名無しさん＠編集中：2014/10/27(月) 00:29:03.26 ID:UcB8ULf1.net

tvRockの後継を開発してた話はどうなったの？

550 ：名無しさん＠編集中：2014/10/27(月) 00:30:51.15 ID:cOwGEDag.net

>>545
次スレ立てればいいだけのこと

551 ：名無しさん＠編集中：2014/10/27(月) 00:33:32.54 ID:wtp+InL6.net

駄文ばかりでなにも生産しないスレを存続させて何のメリットがあるのやら。

552 ：名無しさん＠編集中：2014/10/27(月) 00:48:36.37 ID:LiwXy764.net

>>541
適材適所って事もあるし、俺も別にダメ規格だとは思わないかなー
Caption.dllとかの実装なんて大変だったろうなとは思うけど、仮に文字情報の扱いが簡単な方式だったとしても、
その分別の何らかの方式でスタイル情報を扱わなきゃダメになってただろうし、全体的な手間はそんなに
変わらんかっただろうと思うよ

>>542
そりゃそもそも放送用の符号化方式なんだから、ストリーミングでジャカジャカ流れてくるのを
順次処理していくと言う点が重視されるのは当然じゃないか？

ぶっちゃけメモリに置いてランダムアクセスする場合の苦労なんてそれ程考えてないかと
あるいは、その場合の手間にしたってISO-2022-JPと大して変わらんのだから、そんなに問題じゃ
ないだろと判断したとか

553 ：名無しさん＠編集中：2014/10/27(月) 01:06:40.74 ID:gRav3wl1.net

EPGに関しては仕様上必ず一旦ストアしての組み替えが要求されるので
事情が違うけど字幕に関してはその通りだろうな
一番効率良く字幕を表示するという意味では最適に近い解なんじゃね
字幕を検索する事なんて考えなくていいしな

問題はそれをEPG文字(タイトルだけでなく概要や詳細まで全て)にも適用してしまった事なんじゃね

554 ：名無しさん＠編集中：2014/10/27(月) 01:25:46.14 ID:BX8J4Pu+.net

つか、JISの意味分かってんのかね？
工業製品が工業規格に従うのは当たり前じゃん
馬鹿がUTF8とか言ってるが、UTF8なんて日本語で使うには冗長過ぎる
Unicodeは使える文字多いけど、JISコードすべてを網羅しているわけじゃないし

555 ：名無しさん＠編集中：2014/10/27(月) 01:38:49.43 ID:O5WfWai/.net

自動予約を空にしても発生するEDCBの起動時や再読み込み時の待ち時間の大半が何かだけは知っている
主ニーズが違うんだから字幕と違って制御周りだけは抜くか分けときゃ良かったのに

556 ：名無しさん＠編集中：2014/10/27(月) 01:52:01.52 ID:Jr+fjA7x.net

物分りのいいフリしてすかしてんじゃねーよ
徹底的にやれクソジャップ

557 ：名無しさん＠編集中：2014/10/27(月) 01:53:49.01 ID:jx77baQ/.net

>>554
工業製品であろうとJISだけじゃなくISOでもいいのよ
グローバル（）になりましょう
都合のいいところだけグローバル（）しないで

558 ：名無しさん＠編集中：2014/10/27(月) 05:38:54.80 ID:pYED0ASr.net

>>555
同じいステムの中に複数の文字コードセットw持るほうが混乱するし、全体のソフト作るほうの負荷は
何も変わらない。
EDCBの番組表再読み込みでかかる時間の中でJISの処理時間がどれだけ占めてるのか知らんが、
そもそもTSそのままストアして最初からパーシングしてるのが原因じゃないのか？時間がかかるという
なら扱いやすい形式にしてデータストアする工夫だってある。なんなら、お前がやればいい。

559 ：名無しさん＠編集中：2014/10/27(月) 06:49:39.12 ID:SZPIV5N/.net

制御周りって言ってるんだからJISじゃなくてARIB拡張の話じゃないのか
文字コードセットの話を始めてどうすんだよｗ

560 ：名無しさん＠編集中：2014/10/27(月) 07:16:58.11 ID:dNMrlDCq.net

本来なら検索文字列の側をJISコードに変換して検索かけた方が前加工も不要で
ずっと効率的なのに、混在符号化のせいでそれが出来なくなってんだよなアレ

561 ：名無しさん＠編集中：2014/10/27(月) 07:46:41.84 ID:6VJ47/FK.net

シングルシフトとかモード変更の出現場所とか自由過ぎだからね…
面倒臭いから要求解析とか省略して字幕仕様をそのまま流用しました臭は拭えない

562 ：名無しさん＠編集中：2014/10/27(月) 07:55:40.72 ID:Vg4OY6Ns.net

あいうえお順キーボードみたいな話だなｗ

563 ：名無しさん＠編集中：2014/10/27(月) 12:20:51.16 ID:V7jAaK4K.net

流れぶった切って悪いけど、
TVRockのチャンネル設定がおかしくなって上手く直せないから
Tvmaid使っているんだけど良いねこれ
ありがたく使わせてもらっています

消音、再生オフ、最小化で録画してくれているのはこれがデフォ？
これは助かる

要望なんだけど、
自動予約で無効登録した時にTVRockみたいに無効のまま予約一覧に灰色表示されて欲しい
あと予約一覧画面で日付区切りがあると嬉しいかも
もう開発はあまりしていないのかな？蔭ながら応援しています

564 ：名無しさん＠編集中：2014/10/27(月) 12:24:44.60 ID:6QkU1/kv.net

>>563
そういうのほしいね
tvtestみたくソース公開したら面白い派生が出てきそうでわくてかする

565 ：名無しさん＠編集中：2014/10/27(月) 18:59:58.75 ID:D7T7in+c.net

Tvmaidって録画したTSファイルのファイル名ってどこで変更するの？
TVTest側（RecordFileName）を何に変えても全部下の形になって出力されるんだけど
＞例　ヒーローバンク[字]-141027-1830.ts

TvmaidやTVTestのバージョン変えたりini作り直しても駄目だった
何か見落としあったらスマン　教えてください

566 ：名無しさん＠編集中：2014/10/27(月) 19:41:54.75 ID:6cQc0Bz6.net

ちょうぶんきんし!!

567 ：tvmaid ◆dGJLJP3RhQ ：2014/10/27(月) 20:51:14.10 ID:xcNXu1i8.net

>>563
>消音、再生オフ、最小化で録画してくれているのはこれがデフォ？

デフォ。というかTVRockのようにオプションの設定はできない。

>自動予約で無効登録した時にTVRockみたいに無効のまま予約一覧に灰色表示されて欲しい

無効登録という機能が無い。
自動登録を無効にすると、その自動登録を無視するため、(表示されていないのではなく)予約登録をしていない。
無効登録のほうがいいのかなあ。

>あと予約一覧画面で日付区切りがあると嬉しいかも

これはあったほうが良さそう。

>もう開発はあまりしていないのかな？蔭ながら応援しています

バグ修正はしてるけど、機能追加はやってない。

今のTvmaidは小さな修正だけして、そこからの派生バージョンでテーマに沿った改造、機能追加をする予定。
でも、どういうテーマにするか決まってない...

568 ：tvmaid ◆dGJLJP3RhQ ：2014/10/27(月) 20:52:34.63 ID:xcNXu1i8.net

>>564
>tvtestみたくソース公開したら面白い派生が出てきそうでわくてかする

ソース公開しないと決めてはいないが、今のところ特にメリットなさそうなのでしてない。
もっとユーザが多くないと(というかメジャーでないと)、ソースがあっても派生は出ないと思うなあ。


>>565
残念ながら、変えられない。

userフォルダに、Tvmaid.defというファイルがあって、その中に
record.file={title}-{start-time}.ts

という行があって、これがファイル名なんだけど、
{title}(タイトル)と、{start-time}(開始時刻)しか作ってないので、実質的に設定できない。

569 ：名無しさん＠編集中：2014/10/27(月) 21:05:46.82 ID:6QkU1/kv.net

>>568
ファイル名変えれないのか、俺にとっては致命的だなぁ

570 ：名無しさん＠編集中：2014/10/27(月) 21:08:10.28 ID:lSHAzr8x.net

>>568
自サイトにFAQ欄でも作って回答しないと何度も同じ質問繰り返されることになるよ
というか初めから現状何が出来て何が出来ないのか説明しとかないと質問攻めになるし、このスレにとっても邪魔

571 ：名無しさん＠編集中：2014/10/27(月) 21:31:00.31 ID:D7T7in+c.net

>>568
ありがとうございます
NicoJKのコメント管理でNicojtxtdel使っているのでサービスIDだけでも出力したかったんですけど
無理なんですね　残念です

572 ：名無しさん＠編集中：2014/10/27(月) 22:57:23.10 ID:s4wyF31y.net

　

573 ：名無しさん＠編集中：2014/10/27(月) 23:53:55.53 ID:mY+Lg98R.net

しかしUIデザイン難しいね
先日EPGの件でお騒がせしたけどとりあえずEITはあきらめて
他から入手したんだが日本の番組編成って5分とか平気で入ってるし
それなのに文字文化で大量に文字が必要だからどうやって収めるか悩む

574 ：tvmaid ◆dGJLJP3RhQ ：2014/10/29(水) 18:37:00.18 ID:jH/oOXFQ.net

>>569
他に必要なのってチャンネル名とか？

>>571
ファイル名にサービスIDが必要なのか...
いろんなアプリがあるなあ。

>>570
そうだね。
これまでの質問と回答のページを作るよ。

575 ：名無しさん＠編集中：2014/10/29(水) 19:11:20.11 ID:RT55sEL0.net

>>574
これもtvrockと同じ感じにして欲しい
10項目くらい作ってそれを自由なフォーマットで設定できる感じでも
最低でも放送局名、開始日時、終了日時は欲しい
今はtvrockでこうしてる
歴史発見 城下町へ行こう!SP　明治維新の舞台をゆく〜薩摩、長州、土佐、そして長崎へ [ＢＳ朝日１] 2014年10月26日(日) 13時00分〜14時55分.ts

576 ：名無しさん＠編集中：2014/10/29(水) 20:52:16.95 ID:+SUeXhpfX

エンコード前提なのでロゴ消しや自動CMカットや事前の仕分けなど、チャンネル名はかなり重要

577 ：tvmaid ◆dGJLJP3RhQ ：2014/10/30(木) 17:04:10.80 ID:sqeUpSED.net

>>575
なるほど。作るとき考慮するよ。

578 ：名無しさん＠編集中：2014/10/31(金) 21:00:10.79 ID:ERta9bRx.net

EDCBのクライアントどうなったんだよ･･･
ぐたぐたになりそうだったし、tvmaidの方が技術がありそうだと思ってお願いしたのに･･･
tvmaidに作って欲しかった･･･

579 ：名無しさん＠編集中：2014/10/31(金) 21:03:28.97 ID:dBkyKlbK.net

>>577
俺たちのメイドさん、応援してるよ

580 ：名無しさん＠編集中：2014/10/31(金) 21:12:36.94 ID:rY2y5Tjk.net

>>578
乞食には何かを催促する資格なんて無いってことを理解しろよ・・・

581 ：名無しさん＠編集中：2014/10/31(金) 21:15:56.50 ID:dBkyKlbK.net

>>580
はい、NG

582 ：名無しさん＠編集中：2014/10/31(金) 21:35:24.12 ID:rY2y5Tjk.net

俺かよｗ ま、どうでもいいけど立場を弁えず開発者のやる気を削ぐだけの乞食にはなりたくないわ・・・
ちゃんとした形で要望を出すならまだしも、不平不満ばかりってのはちょっと・・・

583 ：名無しさん＠編集中：2014/10/31(金) 21:47:11.90 ID:ERta9bRx.net

>>582
作るよって書き込みして逃げたんだから非難されるだろ。
tvmaidだってそれが原因でEDCBには手を出さなかったんだから

584 ：名無しさん＠編集中：2014/10/31(金) 21:48:06.78 ID:Hn8aGJsA.net

>>582
ソフト作れない人間に限って無茶な要求出したりするからなｗ
>>575の要求なんかだとバッチ処理で別ソフト処理のほうがいいと思うんだけどね。
一人でやってるっぽいのになんでもかんでも要求してたらパンクするよ。

585 ：名無しさん＠編集中：2014/10/31(金) 22:01:15.75 ID:dBkyKlbK.net

>>584
そんなわけあるかよ
共用してるわけじゃなくてあくまで要望だし無理ならスルーするでしょう
いちいち横槍入れる人うざいね

586 ：名無しさん＠編集中：2014/10/31(金) 22:14:24.81 ID:bYAm9fxW.net

で、要望が採用されるまでしつこく迫ったり
実装されないから叩いたりするんですね
わかります

587 ：名無しさん＠編集中：2014/10/31(金) 22:20:17.82 ID:dBkyKlbK.net

>>586みたいな思考ってキチガイにしか見えないね

588 ：名無しさん＠編集中：2014/10/31(金) 22:42:50.65 ID:SP5R/mLW.net

ID:dBkyKlbKがまともだったのは最初の１レスだけか・・・

589 ：名無しさん＠編集中：2014/10/31(金) 22:47:39.27 ID:dBkyKlbK.net

>>588
なんでだよ
現実的でまともな要望だろ
それに作者は要望欲しがってるからわざわざここでアップしたりレスしたりしてるんでしょ
第三者が憶測で横槍は本当にうざい