P.S. to last post:

The simple solution, to be found if you use the forum search function is to select (on the preview screen) the subtitle box which contains the offending text. Then, press Ctrl-C to copy it, and immediately press Ctrl-C to paste it. You now have a subtitle which consists of two separate boxes. Split your text between the two of them so the top box had half the text of the original subtitle, and the bottom box has the remaining text.

You will no longer have the error message.

If you are good at computers, I would suggest creating a test case which has several subtitles with one line, and several with two separate boxes, as I describe above. Then, export the subtitle using one of the export formats. Look at the structure of the SUB file and see if you can figure out how to quickly look for any line that is longer than "x" characters, and then change that line from one to two boxes. If you know how to do macro programming in Word, it would probably take less than five minutes to create a macro that would do all this automatically. You would then import the result, and voila, no more error messages, and no work to get the result (other than writing the macro one time).

Thanks John for your answers, and the useful links.

I hate it when I don't understand exactly what's happening and why, but it looks like I didn't have any offending, hidden formatting (was copying from Word), or too many characters per line.

I changed Arial to Arial Bold, and voila ! - no errors! (And there were 48 before). Go figure...

I have my subtitles without the black box (Outlined), but I don't feel very comfortable about it. Any possible explanation of this behaviour? TIA

Piotr

I had the same problem a while back, and reverted to the "black box" instead of outlines, but made the black background semi transparent. This way, the titles still stood out no matter what colour was behind, but you could still see the "action" going on.

Yep, I checked - this also works!

But frankly, it beats me why :)

It's been a LONG time since I last did subtitles but I do recall very similar problems to yours. I created the sub file out of an Access database as there was 1,000s of subtitles to do and I could create them automatically, writing the sub file was right up my alley as I write that kind of VB a lot.

Anyway that's almost irrelevant. I recall that if the text was too long to fit on a line I got the same error as you. Changed the code to insert a soft carriage return if the string was over a certain length and that sort of fixed that problem. But as I recall sometimes I still got that error but if I changed font and then changed it back it went away. I certainly got it to work using white Ariel Rounded MT Bold with a black outline.

Bob.

Hi,

I have struggled exactly with the same problem. Imported subtitles that were too "complex" even if they were perfectly readable and within the safe margins.

DVDA should not in the first place allow such "illegal" subtitles, you can easily write such subtitles with its own text editor that does not pass the render...

Why does not DVDA complain about this when editing, but first when starting the render process???

Its like giving a lollipop to a child, and at the time its unwrapped and just going into the child's mouth, you take it away...

Hell of a job to edit unsuitable subtitles if there are many of them. I wonder if this restriction comes from DVDA itself, or from the subtitle standard that puts there some limitations. Still it seems odd if you can fix it by just selecting the box-option.

For me this seems as a bug that never got fixed.

Christian

I agree completely.

What's interesting (and may work with various font / boldness combinations) is that you can turn Outline off (which seems to always allow to avoid those errors), but - instead of leaving those ugly "black box" background - use the outline/background properties to set the transparency. Subtitles use color set 4, and the outline / background color of color set 4 is set to black. To change this, select one of your subtitle events, go to the Color Sets tab of the Properties window, and select the outline / background color setting. By clicking the down arrow to the right, you will be able to edit the color and its transparency, which is controlled by the box labeled "A".

The value of 255 means opaque, while 0 - transparent; I just tested it with various fonts and it works! Also with my original Arial font, NOT set to bold.

Meaning that even though you have Outline set to off, the background box is transparent - looking exactly the same as Outline ON, which is what we want....

Thanks Robert Strobbe Jr for this tip.

My humble thanks also to Robert for this wonderful and butt-saving trick !!!

Did'nt know that from before. This is now a highly valued tool in my work-around toolset - that is growing bigger every...well..month ;)

SCS - please fix this old error in the newxt release of DVDA...

Most annoying thing is the error message is misleading.
When I first struck it I thought the problem was because I was using characters with accents so I changed them all to remove the accents. Not too happy when I found out that was for nought.

Bob.

I presume that the problem is that the software doesn't know if the subtitle bitmaps will compress sufficiently to fit in the bit-budget allowed by the sub-picture stream limit until it attempts to do the render.

As I understand it, subtitles are first rendered to bitmaps and then compressed using a very simple RLE technique. There are only so many bits available for this and if your particular subtitle is "too complex" for the RLE compression to make small enough you will get the error.

In order to reduce the possibility of falling foul of this problem you need to make sure your subtitles, when rendered to the image that will be displayed on the screen, are not too "busy" in the horizontal direction. By "busy" I mean that there are not too many changes of colour on each horizontal "scan line" since the RLE scheme compresses things by, in effect, saying "start off black, stay black for 11 pixels, change to white for 4 pixels, change to black for 8 pixels, etc. The more changes there are between colours on each "scan line" the greater the amount of data will be after RLE encoding.

As can be imagined, changing the font used, or breaking the text lines differently, or changing the font effects used, will all have an effect on the amount of data left after RLE encoding, and hence whether the resulting data is too big for the bit budget or not. I'd guess that as a general rule of thumb using bigger, bolder fonts would be better, and using tricks like outlines would be worse, whilst breaking lines differently might be better or worse depending on other factors.

Mark

I read one post where the poster said that the text was copied from Word. I had a similar problem and solved it by running the text through a plain text editor. I like TextPad, but I think they are no longer around. Notepad or Notepad plus will also work.

I indeed copied my subtitles from Word, and a Polish version of MS Office, too; also, my subtitles contained Polish national characters. Yet - as described above - none of this proved to be the sole culprit.

Incidentally, subtitles don't have to be exclusively Color Set 4 - if you double click a subtitle you can change to a different Color Set in Properties - I use different colours to differentiate between Voice Over and on-camera interviews, or between different characters in dialogue.

As I understand it, each color set can be modified, anyway .

Yes, but changing say Color Set 4 from white to yellow will change every subtitle that has that Color set assigned to it. By assigning different color sets to different subtitles, the subtitles can vary in their colour.

Ach, OK - got your point, Peter. Thanks!