Implementation idea: separating lines by a delimiter instead of the actual timestamps to save up API usage?

[hengyu95]

I got this idea from Subtitle Edit's "Auto-translate via copy-paste" function where they process the .SRT file such that it ends up like this

那就是4万个
*
那其实肯定不止放一个，平均
*
假如说要平均放1.5个，一年6万个支架
*
进口的支架平均一个1到2万块钱

Then you can just toss it into a translator like DeepL and get:

That's 40,000.
*
That must actually put more than one, on average.
*
Let's say it's 1.5 on average, 60,000 stands a year.
*
Imported brackets cost an average of $10,000 to $20,000 a piece.

and the software maps the translation back to the original timestamps since it's a 1-1 mapping separated by each asterisk.

I've been experimenting with this approach with ChatGPT, the translation is often flawless, but the problem is it often ends up combining lines across the asterisks and makes the mapping back desync. But with the functionality of subtrans like batching, validating, re-translating will help enough with this that it becomes a non-problem?

If this works then the consumption of tokens will be largely reduced

[machinewrapped]

GPT is very prone to merging lines, at least in 3.5 - it took quite a few iterations to arrive at the current prompt, which more or less eliminates desyncs. Feeding it lines with a clear indication where it should fill in the translation helps to keep it on track (it just has to fill in the blanks).

Validation/retry could probably fix desyncs even with a looser format... but it more than doubles the token count for the batch, since it has to resend the whole message chain, so it is unlikely to be a net win on that front! :-)

My long term goal is to allow GPT to merge lines when it helps it produce a more fluent translation, then fix up the timings... it doesn't seem able to do that itself, unfortunately - GPT4 might be able to, but it's so much more expensive that I haven't experimented with it much.

[rankaiyx]

GPT is very prone to merging lines, at least in 3.5 - it took quite a few iterations to arrive at the current prompt, which more or less eliminates desyncs. Feeding it lines with a clear indication where it should fill in the translation helps to keep it on track (it just has to fill in the blanks).

Validation/retry could probably fix desyncs even with a looser format... but it more than doubles the token count for the batch, since it has to resend the whole message chain, so it is unlikely to be a net win on that front! :-)

My long term goal is to allow GPT to merge lines when it helps it produce a more fluent translation, then fix up the timings... it doesn't seem able to do that itself, unfortunately - GPT4 might be able to, but it's so much more expensive that I haven't experimented with it much.

Perhaps it can replace the timestamp with a sequence number first, which can both preserve the row location and reduce the token, like this:

That's 40,000.
1
That must actually put more than one, on average.
2
Let's say it's 1.5 on average, 60,000 stands a year.
3
Imported brackets cost an average of $10,000 to $20,000 a piece.

[machinewrapped]

It does actually use an index rather than a timestamp in the translation requests :-)

Just using the index still didn't prevent desyncs though so it requires the model to adhere to a strict format in the response, which essentially compels it to keep lines distinct.

[Neoony]

not 100% sure yet, but I have yet to have the merging issue happen with the newest version of either models chatgpt-4o-latest (I believe they updated it in march and its much better...only available using custom model option) or gpt-4.1-2025-04-14

I just have not used it enough to tell that its 100% gone, but it didnt happen for quite a few subtitles using those models

[Neoony]

Just to update ( maybe a bit too late :D and I guess gpt5 about to drop any moment now )

The merging issue has not happened a single time for me on gpt-4.1-2025-04-14
It just works completely error free on that model
Probably even over 100 translations now since my last post

(using min batch 70 and max 120...and mostly english to czech)

[Neoony]

gpt-5-chat-latest seems to also work fine, but only did few so far

[machinewrapped]

gpt-5, gpt-5-mini and gpt-5-nano all seem to be working OK (not supported in the official release yet - coming soon!). gpt-5-mini seems to be the only one worth using though - gpt-5 is very slow (presumably wasting a lot of tokens on over-thinking) and gpt-5-nano is just terrible, its translations read like old-style machine translated subs 😬

[Neoony]

1.2.0 does not work for me at all though :D
#259

Personally I will be sticking with the gpt-5-chat-latest ( similar to the chatgpt-4o-latest )
For the info:
Its the same 5 model used in the chatgpt app (minus the system instructions I believe)
Gets improvements more often on the same endpoint (dont really know about when it gets updated though)
I just like to experiment and see the improvements, if there are any available and I had good experiences with both chatgpt-4o-latest and also so far with gpt-5-chat-latest in 1.1.2 on the completions API.
(e.g. chatgpt-4o-latest was the first to fix the merging issues suddenly earlier this year, then 4.1 followed which also didnt merge lines)
I dont mind the higher than other models cost, or the speed much (its pretty cheap anyways)

But yeah I think it does not do reasoning.

OpenAI description of gpt-5-chat-latest
"GPT-5 Chat points to the GPT-5 snapshot currently used in ChatGPT. GPT-5 is our next-generation, high-intelligence flagship model. It accepts both text and image inputs, and produces text outputs."
https://platform.openai.com/docs/models/gpt-5-chat-latest

But I will definitely also experiment with the other gpt5 models

I have not had much luck using GPT to have something reworked from completions to responses API for my stuff 😆 , but did not yet try with 5 now. (seems a ton better with code)

---

These might be interesting things to expose, one might set more priority on more cost, other might save cost on lower priority:
https://platform.openai.com/docs/guides/priority-processing
https://platform.openai.com/docs/guides/flex-processing
But its also only for some models.
In the pricing page there are tabs which show the flex and priority processing
https://platform.openai.com/docs/pricing?latest-pricing=standard

But yeah, first better make sure that everything works on responses API as it is :P