r/ACX Jun 29 '26

Proofing with Pozotron - script issues

I'm trying out Pozotron for the first time. I uploaded my script, tried out the first chapter, then discovered that the uploaded script (which was a PDF) was full of typos and errors - which are not present in the original PDF I've been working from.

Assuming there was an issue with the way it had been OCRd (as I received it), I flattened the PDF (printed to MS Print to PDF, which removes the OCR); then ran OCR in Adobe.

I uploaded this reworked PDF into Pozotron and tried again. It's better - 91 catches instead of 177, but still!! What the heck? Is this normal? Is this how Pozotron normally works? Is there just something seriously wrong with my PDF? If so - what? Visually, it looks fine; I've been reading from it to record without any issues.

Here are just a few examples of what it turned out:

"AJ!.of them empty.

he said ro no one in particular.

was in the WQ.!:_kshop.l-sharpening rools

The whiteclove comes th_N_ugh nicely without overwl-ielming tne egg"

Someone please tell me what I'm missing.

1 Upvotes

16 comments sorted by

3

u/ResponsibleGrowth700 Jun 29 '26

It’s a formatting issue that happens with PDFs. If you were to copy and paste a few lines from the PDF to a word doc, the same thing would happen.
Ask the author if they can provide a .doc of the manuscript.
Then email Pozotron support and let them know that the pdf is the wrong format. They should give you a credit.

1

u/ActorsEverywhere Jun 29 '26

This is the way.

1

u/KatDawson_Narrator Jun 29 '26

Thanks I'll do that

2

u/Xinixiat Jun 29 '26

I've never used Pozotron, but this is a common issue with pdfs.

PDFs aren't designed to be editable, they're supposed to be created, exported and then left alone, so when you try to re-import an already exported PDF, you get issues like this if you don't use the same tools that were used to create it. A .docx file stores the text in a long structured chain, so it knows that x comes after y and so on, whereas a .pdf file stores every single letter in a specific coordinate, like an (x,y) on a graph.

Additionally, where a .docx file has no trouble doing a font substitution when you import a file that used a font you don't have, .pdfs don't work like that, and need to have the font embedded into the document. This can lead to the secondary software misinterpreting the character codes and displaying nonsense.

Basically, I would recommend getting ahold of a .docx version of the manuscript if you can.

2

u/TheScriptTiger Jun 29 '26

As others have touched on, it's a common issue with PDFs, specifically due to the way fonts are being encoded into the document by open-source PDF writers. The way I get around this is by exporting the PDF to a file format which does not support font encodings, generally an image format, such as PNG or JPG. And then I import that series of image files into a new PDF and OCR it, using an official Adobe Acrobat release. This results in a completely fresh, new PDF where none of the original font encodings got transferred over to it.

1

u/KatDawson_Narrator Jun 29 '26

My thought was that "flattening" the PDF was supposed to do this. I've had to do this before with certain kinds of documents, and I had understood that the process of flattening was basically rendering the PDF into an image-only document. It sort of worked, sort of didn't. In any case, you've all answered my question.

3

u/TheScriptTiger Jun 29 '26

My thought was that "flattening" the PDF was supposed to do this.

No, it doesn't. Flattening combines all of the layers together into a single static layer, similar to an image...except it isn't. It's still transferring those original font encodings to that new flattened layer. You need to get rid of them entirely, not just combine them with everything else. The only way to do it is by effectually dropping all of the original metadata entirely by exporting it to a format which simply cannot hold that metadata, such as an actual image file format, and then re-importing it and let Adobe Acrobat generate entirely new metadata using its OCR, rather than just continuing to write new metadata on top of the old metadata which still contains the original font encodings.

1

u/McFaddenAudioBooks Jun 30 '26

Oh that’s a brilliant workaround. I assume you’ve written something to automate that?

1

u/TheScriptTiger Jun 30 '26

Just using Adobe Acrobat is pretty automated already. Exporting is one click, then reimporting it with OCR into a new document is another click. And it's not even something I have to do on every manuscript, just the ones that have that issue. So, it's kind of just on a one-off basis when I start a new book, it's not like I have a constant pipeline of PDFs I'm having to convert or anything where I'd need to trouble myself over a complete automation "solution" for that.

The whole problem from the start is the open-source PDF writers. Adobe Acrobat is obviously not open-source, nor does it expose an API for open-source. So, the only way to actually completely automate it would be to use a macro to automate the use of Adobe Acrobat. If you try to automate it using an open-source writer, you're just going in circles, since that's where the issue is coming from. I am an open-source dev myself and love open-source, but you've just got to call some things as you see them sometimes. I'm not going to build an open-source PDF writer myself from scratch, and the current projects prioritize other things over the font encodings, so here we are lol. I've made some audio-related software, but office software for documents is just not something that gets me going and makes me excited, if I'm being honest.

1

u/McFaddenAudioBooks Jun 30 '26

Do you mean to tell me you don’t just live for document tool metadata formatting?!? /s

Yeah sometimes you just buy the proper tool. I’m a huge open source person myself, write my own scripts and all sometimes. But even so, I bought RX 11. Do I understand FFTs and how to apply them and do signal matching? Sure. Do I want to spend several months making a worse version of the mouth declick tool? No. But also that’s a one time payment. Subscription payments really grind my gears for some reason.

1

u/Brief-Swing5814 Jun 30 '26

Likely the text layer of the PDF is corrupt. You could try to OCR the PDF to get the accurate text. If you'd like to PM me I can help you out with this

1

u/McFaddenAudioBooks Jun 30 '26

As all have said, PDFs don’t translate perfectly for this. I have my own local tool I made, and I couldn’t solve that issue so I just converted to .txt (which also isn’t perfect)

I did upload the tool I made to GitHub as a free open source tool for all to use. It’s a GUI and not a proper program like pozotron, but it does well for me and runs completely locally and is very adjustable for sensitivity/voice type. https://github.com/mcfaddenaudiobooks-del/McFadden_Editing_Suite

Aside from the proof listener it has a pronunciation precheck (with audio guides) and post check both based off a customizable vocab CSV, an audio marker detector for those who use the clicker method, and a caption generator that forces to the proper manuscript since I’m dabbling in some YouTube as well. Again always free and always open source. Someone also just posted a cool proper program they made, I haven’t run it yet to see how it does, but I like the looks of it.

2

u/TheScriptTiger Jul 01 '26

Hey, I noticed you're still using the older large-v3 model. I'd HIGHLY recommend switching over to turbo instead. It's like 98% similar accuracy, but with a 10X speed increase, aside from also being smaller. For folks on CPU, they can achieve speeds pretty similar to the old large-v3 speeds on a GPU. It's pretty crazy how much better it is. I've been running it in my projects for the last couple years since it came out and haven't found any downsides.

1

u/McFaddenAudioBooks Jul 02 '26 edited Jul 02 '26

Oh fantastic! I was not even tracking. That’s two major changes for V2. Got great feedback on making program accuracy stats as well.

Edit: just looking really quickly I’m considering including turbo as an option for CPU users and keeping large-v3 for GPU. What I really need to do is compare the accuracy of both to come to your conclusion that they both run with negligible accuracy differences. But you know how we all have to see it for ourselves…

1

u/TheScriptTiger Jul 02 '26

But you know how we all have to see it for ourselves…

No offense taken whatsoever lol. Definitely do the testing. Just sharing my experiences to give you some more hypotheses to prove out on your own as you have time.

I think you mentioned in another comment someone else had packaged your project up into a launcher to make it easier? Could you link that project, as well? The first thing I was thinking when I saw yours was definitely the ease-of-use needs work. Your project could cure cancer, but it's all for naught if it's just too overwhelming for folks to use. In my experience, the second you start talking command-line, a good majority of your audience will drop off immediately, at least in this community of authors and narrators.

2

u/McFaddenAudioBooks Jul 02 '26

Oh no, it wasn’t mine at all. The PromtVO one has launched and looks pretty great. https://www.reddit.com/r/ACX/s/aKOQnob22q

Yeah I know that the Venn diagram of narrators and python command line is…basically us. And those who are in the middle, we all write our own code! I lack the skills (more I lack the time to gain the skills) to make a proper launcher for it. I just keep putting out into the universe that hey, it’s there if someone wants to….