音声付き電子書籍の作り方【6】【制作編】読み上げる文章を抽出する
【制作編】読み上げる文章を抽出する
easy_epubフォルダにあるサンプルファイル「text-file」をエディタで開きます。
(拡張子がなくてうまく開けない場合は、拡張子「.txt」をつけて「text-file.txt」としてください)
同梱されているサンプルのテキストファイルです(text-file)
このサンプルファイルの冒頭に
（（句読点でspanタグ））
(「カッコカッコ句読点でspanタグカッコカッコ」)
という一行を記入してください。句読点「、。」単位で文章をピックアップできるようにします。
（（句点でspanタグ））と指定すると、句点「。」単位になります。
長編などで句読点単位だと音声ファイルが細かくて多くなりすぎたり、HarukaやOtoyaが短かい文章だと読み間違いしてしまうような時に、句点単位の方が良い場合もあります。
また、WINDOWSの場合は、say_easy_epubで音声をつける時にひとつの音声の最後に少しマージンの間が入ってしまうので、句読点単位よりも句点単位で区切った方が聞きやすくなります。
一行記入したサンプルファイルを保存したら、easy_epubの以下いずれかの方法で電子書籍ファイルを作ります。
1)EasyEpub.appにtext-fileをドラッグ＆ドロップ(Mac)
2)easy_epub.batにtext-fileをドラッグ＆ドロップ(WINDOWS)
3)easy_epubフォルダでターミナルやコマンドプロンプトを開いて
「perl easy_epub.pl text-file」
とキーボード入力(Mac WINDOWS)
この後、ターミナル、コマンドプロンプトを使うことになるので3番目の方法がおすすめです。
作成した電子書籍ファイルの中は以下のように、句読点ごとにHTMLのspanタグで区切られています。
文章によって句読点と鉤括弧類(「」『』)の規則が違うので不整合を起こす可能性があります。ここで一度epubcheckを使って電子書籍ファイルのエラーをチェックしてください(サンプルファイルではエラーもなく問題はありません)
ターミナル、コマンドプロンプトをeasy_epubフォルダを開いて以下のコマンドをキーボード入力します。
perl epub_check.pl 20151213151805.epub
※「20151213151805.epub」は作成した電子書籍ファイル名です。
「エラーも警告も検出されませんでした」と表示されたら電子書籍は問題なく作成されています。
(初めてepub_check.plを起動すると、epubcheckの最新版をダウンロードしますので、少し時間がかかります)
次に「say_prepare.pl」を使って、読み上げる文章をピックアップします。
ターミナル、コマンドプロンプトをeasy_epubフォルダを開いて以下のコマンドをキーボード入力します。
perl say_prepare.pl
SPAN:498:WORD:498 ...count OK
という表示が続いてます。
これは、句読点句切りからピックアップした文の数が合っているかのチェックです。「OK」と表示されていたら問題はありません。
NGと表示されていたら元の文章をご確認ください(だった。」』そして、などと句読点や鉤括弧が複数連続して並ぶとNGになる可能性があります)
say_prepare.plを実行すると、easy_epubフォルダの中に「_voice」というフォルダが作られます。
_voiceフォルダの中には以下の3つのファイル、フォルダがあります。
・_span_split_txtというテキストファイル
・multimediaという空のフォルダ
・textという本文テキストの入ったフォルダ
textフォルダに入っている本文は、句読点句切りの電子書籍ファイルに句読点単位でIDをつけています。
「_span_split.txt」というテキストファイルが読み上げる文章を記述したファイルです。
textフォルダの本文についているIDと、句読点で区切られた文章が一行ずつ並べられています(タブ句切り、文字コードutf8 BOM無)
このファイルを元に音声ファイルを作ります。
say_easy_epubでは、ルビがふってある文字はルビを読みとして_span_split.txtに登録しますが、ルビ以外のところで合成音声の読み間違いなどがあります(「町」「まち」を「ちょう」と読む)
読み間違いや人名、当て字など、この_span_split.txtで平仮名に直したりしながら編集・修正していきます。
音声付き電子書籍の作り方【7】「【制作編】音声ファイルを作る」に続く。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
KDPセレクトで無料キャンペーンや70%著者印税
KDPセレクトプログラムに参加させた『陽だまりうたた寝若桜』（日野裕太郎・みさわりょう） http://www.amazon.co.jp/dp/B00A12F30E で、12月9日（日）17時頃〜10日（月）17時頃までの約24時間、無料キャンペーンをやってみた。
結果を見ると、日本とアメリカ、ドイツのアマゾン、Kindleストアで合わせて30冊強ダウンロードされていた。
その後、有料版も少し出ていた（もしかして、無料だと思って買っていただいたのだったらすみません。厳密に何時〜何時じゃなくて、何時頃〜何時頃なので）
一日のキャンペーンでこのぐらいダウンロードされる＝読者に届くのなら、KDPセレクトプログラム、90日の期間中、無料キャンペーンは5日使えるので残り４日分、タイミングを見てまたやってみよう。
世間的には年末年始の休みで、移動時間や実家で退屈に過ごす時間が狙いどころのひとつ。また、年末年始のkindleオススメ本を探してる、仕事として電子書籍に関わるひとたちがいるから休み前の平日を、あざとく狙うのもひとつ。
試行錯誤してみる。
日本の販売でも70%ロイヤリティが設定できるようになっていた。
日本KDP公開当初は35%ロイヤリティ（著者印税が35%）しか設定できなかったが、12月14日に改訂されたらしい。
その条件として。
・KDPセレクトプログラムに参加すること。
データについてはアマゾン、Kindleストアで専売とすること。
無料貸出しに応じること（これはまだ日本じゃ著作権がらみでOKになってない）
・紙製本版で同じ本がある場合に販売価格は紙製本版の80%以下にすること。
・価格が 99円〜20000円 250円〜1250円まで。
また、配信手数料が１Mあたり１円かかる（たとえばアメリカは＄0.15なので格安設定だ。日本は漫画が主力だからここは安くしたなあ）
ということで、（単価ー配信手数料）x 0.7となるようだ。
ウチの場合。
今のところKindleストアに登録しているのは、絶版の同人誌が中心（まだ在庫のある本、紙製本版は e託にまとめて委託をお願いしている）なので、値段設定に悩むところはない。
配信手数料も、小説本で、テキストと表紙に画像が一枚だけなので、ファイルサイズは1M以内、1円で済む。
iPhone電子書籍で販売中のものが専売にひっかかる。ぶっちゃけiPhoneの電子書籍アプリではまるで売れないけど、これは乗りかかった船なので、このまま展開しておいて、iTunesのアカウントが切れたら見直すことにしよう。
とりあえず、KDPセレクトプログラムに投入できそうなものを選んで、これもまた「お試し」ということでやってみよう。
[12/17 14:34:56] 追記。こっそりでもないけど。（あまり具体的に言うと規約的にまずいらしいんでボカした状態で）10月26日から本を徐々に並べて、今日時点約１ヶ月半。計７冊販売で売り上げ数は、無料・有料合わせてぎりぎり３ケタあたり。11月一ヶ月の売上数を12月はすでに上回っている。端末がユーザーのところに届き始めてるのか。たぶん現状は先行有利なだけで、いわゆるアーリーアダプター（物好き）が買ってるだけだろう。本好きが流入してきてからが本番。少しでも目につくように、本の数を増やしておきたいなあ。
- 『おかえりください』サウンドノベルWINDOWS版
- 『おかえりください』本編を加筆修正、６つのバッドエンド分岐シナリオを追加してサウンドノベル化！
音と映像が、血まみれのこっくりさんの惨劇を蘇らせる。 - 【無料体験版】はこちら
EPUB3で縦書き小説を作成、Kindleストアに並べるならこちらが簡単
→ EPUB3::かんたん電子書籍作成
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» Kindle(109) » KDP(62) » 電子書籍(282)
創作文芸見本誌会場HappyReading
必要だろうと思った機能を最低限つけて、バグをひとつずつ潰して、まず最初の完成形となった。
とりあえずのメモ。
データベースは、mysqlではなくてsqlite。
どうして？lolipopのmysqlは重いので、ページ表示がもっさりしてしまう。レスポンスが早い、というのがwebの絶対正義。
sqliteは複数の同時アクセスに弱いという評判だけど？確かにその通りらしいけど、ウチぐらいのアクセスなら十分。むしろファイルひとつがそのままDBなので、バックアップなどのメンテがらくちん。そっちのメリットのほうが大きい。
mysqlとかpostgresqlのようなRDBが必要になったら、そのときそのままSQLなどは移せる。
データ構成は。
基本的に、一意に決まる本の情報以外の付属情報はすべてタグとして処理。著者やカテゴリなど。でも、イベント情報関係は別テーブルで管理（同人誌の場合、イベント参加情報は重要なので）
詳細ページを閲覧された回数や立ち読みされた回数はまた別管理で。モチベーションのため。
ページ表示に使うためのマスターテーブルは特になくて、idではなくて、ユーザー入力によるテキストのタイトル部分をキーにしている、というのが後々禍根を残しそうな予感。でもたぶん、そのおかげでおそらく内部SEO対策となる、はず。urlとページタイトルとコンテンツのh1の関連が強くなるし、そこで使われるキーワードがアンカーテキストとしてページ上部に出現する、いわゆるSEOとしては理想的な構造。
サイトの目的とか。
立ち読みをしてもらう。
面白かったら作者やサークル、カテゴリで芋づる式に次の立ち読みをしてもらう。
動線はそのために作る。それによって結果として内部SEO対策となる。
表示側。
一覧ページと詳細ページだけ。あとは、利用規約など。
サイトのトップページは必要ない？意図を持ってなにかをおすすめするとか企画するようなサイトではない。なので、単純にひらたく、なんらかの一覧ページをトップにすればいい。
ページの目的は立ち読みのテキストを読んでもらうことなので、一覧も詳細もワンクリックで立ち読みが開くように。
サークル名や著者名など本に付属するデータはすべてリンクとする。面白かったら芋づる式に次を読んでもらいたいから。
登録側。
テーブル構造のまんま。必須項目などはjavascriptでUIを作る。必須入力項目が多いので、少しでも便利にしておきたいところだけど、まだまだ検討材料が多い。
同人誌に限った話ではなくて。デザフェスなんかを見て感じることで。
世間とか時代とかに、もし閉塞感があるとすれば、これからは組織に頼らない個人こそが勝負できるんじゃないかと思う。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
縦書き twitter その後
APIを使って、取得したtwitterのデータを縦書きで表示する、名づけて「たてたったー」に、擬似縦書きもどき入力フォームをつけて、入力時にも縦書きで確認できるようにしてみた。
ttp://www.holeinthewall.jp/~butch/zakki/tatetatter.pl
こういう小ネタはjavascriptの出番。prototypeとかjQueryを使うまでもなく、textareaに入力された文字を keyup のたびに読み込んで、用意したdiv要素の中に表示していく。一見リアルタイム。
縦書きで表示するのは、ミソというかコロンブスの卵というか、float:rightした、幅 1em のdiv要素に流し込むだけ、という呆気なさ。CSSだけで縦書き表示はできるので、javascriptと組み合わせてこんなこともできるありがたさよ。
おもしれーっす。
[12/18 23:13:36]
ついでに。
ajax使って、新着情報を取りにいくようにした。公式のWebの「新しいツイートが？件あります」というアレだ。javascriptは好きじゃないので、悔しいけど、便利。
ついでに。
過去記事も見られるようにした。
どちらも since_id とか max_id をパラメータに渡してやればいいだけ。このシンプルさがいいところだ。欲しい情報を伝えればそれだけを返してくれる、のでなんか作るにしてもテキトーなものだったらスグにできちゃう。ネタ勝負。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» twitter(28) » web(174)
いつになるかわからない覚書
現状、仕事がらみだと「自分ＯＫ」で動けないのでじんわりずしりストレスがたまるばかりだ。思い返すと、仕事でも「自分ＯＫ」でやってきた期間が長くて、その間、あれこれそれなりにやってきたんだけどなあ、と。まあ愚痴っててもしょうがないんで、ウチのポンコツサーバー読書SNSのリニューアル画策。
国立国会図書館のサイトもどうやらAjaxだらけだし、ウチもAjaxを使ってページ遷移を少なくしてみよう、てのが基本方針、か。HOME画面とMy本棚画面だけで全部用が足りる、居間と書斎、たまに図書館、という雰囲気になればいいんだけど。
となると、HttpRequestに対応していないzaurusでは見ることができなくなる部分が増えるので、今までこだわってきた横幅640pxはもういいや、と。とはいえ、国立国会図書館やmixiのように1024pxで横スクロールが出るのは論外だし、とりあえず横幅800pxにして、ヘッダ部分を作った。
んで、見た目のチェックを兼ねてダミーページにおいてみる。IEだのFireFoxだの、borderとかpadding、marginなんてしょうもないところに時間をかけたくないので、今回は（そのあたりの問題が少なそうな）xhtmlで書いてみることにした。…どう考えたって、ブラウザごとの違いに振り回されるなんて、時間の無駄労力の無駄でしかないし。
ナビゲーションのタグは一枚画像で作ってスタイルシートで切り替えだ。これは簡単でいいぞ。
なんせ一枚画像なので管理が簡単。
onmouseoverなんてのがhtmlに交じり混まないのでhtmlが簡単。
htmlをすっきりさせられるのでperlのほうもすっきり簡単、になりそう。
いまさら改めて、スタイルシートって便利なものだ、と感心してしまった。idとclassを 適当に 適切にふっておけば、見てくれは後からでも間に合う。
ついでに角丸のライブラリでも探すかと思ったら、これまたスタイルシートだけでできるというので驚き。いちいち書くのは面倒だけど、perlで部品化しておいて書き出すだけにすればいい。
ただ、角を丸めるかどうかはまた別の話。ウチのサイトだと、なんかちょっと違和感があった、かも。色づかいかなあ…使いどころだろうけど。
さらについでに、どうせprototype.jsを使うし、なんか使えそうなものはないかと探してたらcookiemanager.jsを発見。セッションIDの邪魔にならないようにして使えるなら画面の小細工に使えそうだ。JavaScriptでcookieをいじれるのはラクだろうし。
スクリプトとDB問い合わせを見直して、ちょっとずつ作っていくか。ううううむ、いまの調子だといつになることやら。ほんと、時間がほしいぞっ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 日常(962)
師走は忙しくて当たり前か
いや、忙しいのだ。12月だからしょうがない。なのにおかしな体調はなんとかならんのか、歯も含めて。
今年は26日が仕事納め。
22日は会社の忘年会で夕方以降仕事にならない。
24日は大掃除で昼間は仕事にならない。
26日の仕事納めはほとんどみんな夕方まで。
実質、フルに仕事になるのは今週と来週25日だけ。んでもって、来週下版しなきゃいけない、もしくは大半を下版しなきゃいけないのが、しっかり2冊分。手元に原稿を寝かしてる余裕などどこにもなく、機械的に処理していきたいところ。…なんだけど、あんな会議やこんな会議などなどがあって、その余波・飛び火で、仕事を中断させられやる気を削がれる。
サラリーマンのクビのちょうつがいはタテにしか動かないんだから（とくにうちのようなオーナー社長の企業では当たり前）もう少し分かれよ、てなことだったりする。理不尽なことならともかく、そりゃお前もおれも、言われてもしょうがなかろう、ということだし。赤字出してなければ文句なんて言われっこない、ということを謙虚に、だわ。
そんなこんなでも、一度手をつけ出したらキリがないのが、CGIパズル。この雑記帖スクリプトのバグを直してみたり、検索での使い勝手を改良してみたり。スクリプトがきちゃないんで、クリンナップしたいし、ついでにちょっと機能追加してみたいなぁ、とか。
ここんとこネットや書店のその手のコーナーで見かけるようになった、RSSとかBlogとか、かなり気になる。だけど、それがどういう仕組みかはともかく、それによってなにができるのか、を分かりやすく見せてくれるサイトとか解説本が（立ち読みする限り）ないんだよなぁ。
なんだってそうだけど、「とっかかり」は、その仕組みになんて誰も興味はないのだ。それによって何ができるか・変わるか、が知りたいのだ。それが面白そう・有益そうであれば、導入して、さらにそのメリットを享受するために「仕組み」に関して踏み込んでみる。というのが自然な流れだろう。
美味い料理を食って初めて、なんでこんなに美味いんだろうと思って、それじゃ、調味料は・火加減は、とか関心を持つようになるのだ。
現状、わたしには、RSSとかBlogとか、美味いのかどうかもわからないので、導入にいたってないんだよねぇ。
わたしにRSSとかBlogの美味しさを誰かおしえてたもれー。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
