don said:
>   It's pretty hollow.

not surprising.  even the article put it all
in the future tense.  and h.p. talked about
"potential", while amazon merely confirmed.

>   >   This book has not yet been processed,
>   >   but if you preorder we’ll process it faster
>   >   and notify you when it’s ready.

>   Right.

it makes perfect sense to me.  how else would
you prioritize which books should be done first?

as for skepticism on the time-frame, how much
time do you think it'll take 'em to prep a book?
i would guess that it's a matter of mere minutes.
(seconds for the scripts to run, and then a minute
or two for a human to execute the quality-control.)

***

jim said:
>   bookprep

thanks for running that down, jim.  good info.

***

gardner said:
>   What's your point?

"what's my point?"

well, it's pretty obvious, i would think, isn't it?

if h.p. is correcting the o.c.r., that's a big deal.
but if they're just printing the scansets, it's not.
so there is an informational asymmetry at work.


>   If there are pages missing or illegible sections,
>   then it might be better to skip that volume,
>   versus go ahead selling it to folks who are
>   likely to complain or return it. 

ok, i see what you meant when you said "proofing";
i consider checks like that to be "quality control"...

those problems were common in the first few years
of the google scanning, but are fairly rare nowadays.


>   But if you're lazy, you'd skip that step and let the
>   customer inform you if a given volume is unusable.

well, we differ on terminology again, because i wouldn't
call that "lazy", as it's more like a business decision, but
i'd think a quick screening for those types of problems
would be cost-effective, as opposed to making good on
any complaints that your customers would have later on.
shipping is gonna be one of your biggest expenses, and
shipping a book twice, to make-good, will be expensive...
(not to mention a costly infrastructure to field complaints.)


>   If you get a lot of complaints about a specific volume,
>   you can then go and figure out what exactly is wrong
>   maybe find a fill-in source or what have you.

the "fill-in" source is likely right there in the umichigan stacks.


>   But why take on that work up front?

again, google and michigan have each separately worked
on correcting these problems, so i'd think very few remain.
and a quick check by h.p. can eliminate any glitches that do.
i'd guess most of google scanning nowadays is clean-up work.


>   People will pay the same whether you invest up front or not.

but people will only pay once for a book.  so if h.p. has to
print and ship _two_ books to make that customer happy,
they've lost money on that sale.  that's why they'd "invest",
up-front, to ensure they won't have to face that prospect.

at least that's _my_ take on your particular point here...

i guess real life will show us whether you're right or i am.

-bowerbird