Scn 3.4 and LB

srfscenar · 12th May 2016, 10:12

Hi all,

My project although it seems to be within file sizes
Scenarist keeps rejecting it as oversized.

I use 3.43 and I know it's buggy but I did not expect that much.
Here is a screenshot: http://postimg.org/image/8t9z8bqo1/

Any suggestions? Other than re-encoding the whole thing which will be the last resort.

Thanks...

rik1138 · 16th May 2016, 23:56

Yeah, you might be over the total disc capacity after the image is created... I always hated that part of doing a dual layer disc. It can fail in one of three places- Making the mux, making the disc image, and making the replication image. I've actually had a disc get through the first two, but fail when making the final replication image, _that's_ annoying as it's already been through QC at that point...
As a general rule, I never exceed 95% on a layer, that usually works.
You obviously have to move the layer break back a little bit, which is likely to make layer 1 too big. Something is probably going to have to be encoded a little bit smaller...

kolak · 17th May 2016, 23:09

Yes, you can't rely on the info about layers size until you do final image.
Your layer 0 is simply to big. Try moving layer break point or you need to do new encode.

srfscenar · 18th May 2016, 12:55

Thank you guys, I was hoping to avoid re-encoding as changing the lb is not an option.
I remember older versions, 2.6, 2.7, were more accurate about this.
Anyway, I'll live with it!

Thank you both!

mp3dom · 23rd May 2016, 19:40

Use 3.3.2 which is the best version available. The layer break calculation is like previous versions (more accurate) and lots of bugs were fixed. 3.4 is full of new problems, and the layer break calculation is just one of those.

12th May 2016, 10:12	#1 \| Link
srfscenar Registered User Join Date: May 2003 Posts: 492	Scn 3.4 and LB Hi all, My project although it seems to be within file sizes Scenarist keeps rejecting it as oversized. I use 3.43 and I know it's buggy but I did not expect that much. Here is a screenshot: http://postimg.org/image/8t9z8bqo1/ Any suggestions? Other than re-encoding the whole thing which will be the last resort. Thanks... __________________ " 2 minds are better than 1 "

18th May 2016, 12:55	#4 \| Link
srfscenar Registered User Join Date: May 2003 Posts: 492	Thank you guys, I was hoping to avoid re-encoding as changing the lb is not an option. I remember older versions, 2.6, 2.7, were more accurate about this. Anyway, I'll live with it! Thank you both! __________________ " 2 minds are better than 1 "

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

16th May 2016, 23:56	#2 \| Link
rik1138 Registered User Join Date: Mar 2008 Location: LA Posts: 620	Yeah, you might be over the total disc capacity after the image is created... I always hated that part of doing a dual layer disc. It can fail in one of three places- Making the mux, making the disc image, and making the replication image. I've actually had a disc get through the first two, but fail when making the final replication image, _that's_ annoying as it's already been through QC at that point... As a general rule, I never exceed 95% on a layer, that usually works. You obviously have to move the layer break back a little bit, which is likely to make layer 1 too big. Something is probably going to have to be encoded a little bit smaller...

17th May 2016, 23:09	#3 \| Link
kolak Registered User Join Date: Nov 2004 Location: Poland Posts: 2,843	Yes, you can't rely on the info about layers size until you do final image. Your layer 0 is simply to big. Try moving layer break point or you need to do new encode.

23rd May 2016, 19:40	#5 \| Link
mp3dom Registered User Join Date: Jul 2003 Location: Italy Posts: 1,135	Use 3.3.2 which is the best version available. The layer break calculation is like previous versions (more accurate) and lots of bugs were fixed. 3.4 is full of new problems, and the layer break calculation is just one of those.