New FW for NEC 3500 2.1A and 3520 3.05

[Scour]

http://support.necsam.com/OEM/downloads/FlashFirmware/

[rahzel]

anyone know the changes in 3.05 for the 3520?

[ala42]

Here are the changes compared to 3.04

Code: Select all

DVD+R   supported media types:  146
AML      003-000 16x,12x,8x,6x,4x
BeAll000 PG0-000 16x,12x,8x,6x,4x
DAXON    AZ3-000 16x,12x,8x,6x,4x
GSC503   H02-000 16x,12x,8x,6x,4x
LGEP16   001-000 16x,12x,8x,6x,4x
MAM      M04-000 12x,8x,6x,4x
MJC      005-000 16x,12x,8x,6x,4x
MUST     006-000 16x,12x,8x,6x,4x
NAN YA   FLX-000 16x,12x,8x,6x,4x
NSD      R40-000 16x,12x,8x,6x,4x
PRODISC  R05-001 16x,12x,8x,6x,4x
RITEK    P16-000 16x,12x,8x,6x,4x

DVD-R   supported media types:  373
80SONY-R0       4x,2x
Dvsn-160        16x,12x,8x,6x,4x
GSC005          16x,12x,8x,6x,4x,2x
ISSM R01        8x,6x,4x
LGE16           16x,12x,8x,6x,4x,2x
NAN YA F02      12x,8x,6x,4x
RITEKM16        16x,12x,8x,6x,4x,2x


Speed of GSC005 was changed, all other MIDs are added.

[Scour]

Helllo!

NEC 3500-FW is not supportet by MSCE?

Anyone found a changelog?

[rahzel]

i think its kind of dumb that NEC doesnt post the change log for their firmware. I e-mailed NEC asking what the changes were.

[ala42]

NEC 3500-FW is not supportet by MSCE?

Supported since yesterday

[Scour]

NEC 3500-FW is not supportet by MSCE?

Supported since yesterday

I download the newest version but it doesn´t work with 2.1A?

[ETP]

Is 2D still better than this FW for the 3500?

[ala42]

I download the newest version but it doesn´t work with 2.1A?

It does not display the +R9 codes. Everything else works like it should, so you can replace write strategies.

[Scour]

I download the newest version but it doesn´t work with 2.1A?

It does not display the +R9 codes. Everything else works like it should, so you can replace write strategies.

Sorry, my mistake. I used the older version, the new works

[frank1]

Does anybody know if a corresponding firmware to this NEC 2.1A is going to be published
by Mad Dog soon ?

[frank1]

According to this topic the new 2.1A firmware by NEC
does not support disc quality scanning with CD-DVD Speed.

So it is unfortunaly not the long awaited 2R8 firmware

[dolphinius_rex]

According to this topic the new 2.1A firmware by NEC
does not support disc quality scanning with CD-DVD Speed.

So it is unfortunaly not the long awaited 2R8 firmware

I actually consider that a good thing!

[RJW]

According to this topic the new 2.1A firmware by NEC
does not support disc quality scanning with CD-DVD Speed.

So it is unfortunaly not the long awaited 2R8 firmware

I actually consider that a good thing!

?????
A good thing ? In a way like that NEC can still release another firmware ??

[frank1]

I actually consider that a good thing!

Your opinion is interesting,
but I would like to know why do you think so:

- the NEC 3500 and 3520 do not report well the errors
- we have already enough different readers used for CD-DVD Speed disc quality scans
- or for some other reason ...
Thanks

[dolphinius_rex]

I actually consider that a good thing!

Your opinion is interesting,
but I would like to know why do you think so:

- the NEC 3500 and 3520 do not report well the errors
- we have already enough different readers used for CD-DVD Speed disc quality scans
- or for some other reason ...
Thanks

How about all 3

#1 Yes, I don't think the NEC (or Pioneer) drives are very good testing units.

#2 Yes, I think there are already enough drives capable of testing media, mainly because...

#3: ... there are too many people posting scans made on drives, making comments about things they don't understand, and have no intention of ever trying to understand properly. So many people have adopted error rate scanning as a way of testing media, without actually knowing how to use it effectively. I think it more people spent time looking at transfer rate tests it would be far more effective... or (more importantly), far less destructive! It's not hard to find a scan that looks good, even if the disc is bad... or vice versa. And a noob with only a tiny bit of experience and real information is a VERY bad combination.

So the longer NEC's can't do testing, the better, in my opinion.

[frank1]

Thanks dolphinius for your very interesting comment
I am also a bit lost with all these scans

I noticed only recently that CDRinfo in their reviews use in a systematic way
CD-DVD Speed data transfer rates
made with drives where they have overspeed the reading capabilities
See for example here for the Pioneer 109:
http://www.cdrinfo.com/Sections/Reviews ... &PageId=13
And they on top of each webpage this comment:
" In general, a "perfect" disc should have a smooth reading curve .........
Most times however, even though a disc has very low PIE/POE error rates, the reading curve may not be smooth containing dropoffs. Due to the fact that we oversped the reading capabilities of the LiteON SOHD-167T, such drops are expected, especially near the outer area of the disc "

So maybe I should get interested in flashing my readers such as Plextor PX-116A, Toshiba SD-M 1712 and 1802 with modified firmwares ?

[Ian]

Yeah, but when you have a drive that normally reads +R/-R discs at say only 8x, over speeding is necessary. Otherwise they all look "good".

I do the same thing for our testing, but I have the read speed set at 12x, not 16x.

[frank1]

Thanks Ian
I should in the future also read more in detail the reviews here at CDRLabs

[Muchin]

#3: ... there are too many people posting scans made on drives, making comments about things they don't understand, and have no intention of ever trying to understand properly. So many people have adopted error rate scanning as a way of testing media, without actually knowing how to use it effectively. I think it more people spent time looking at transfer rate tests it would be far more effective... or (more importantly), far less destructive! It's not hard to find a scan that looks good, even if the disc is bad... or vice versa. And a noob with only a tiny bit of experience and real information is a VERY bad combination.

So the longer NEC's can't do testing, the better, in my opinion.

I can’t agree more with your comments. IMO, unless manufactures are willing to adopt a common way to implement PI/PO error detection, the chaos will remain. I have just noticed, to my surprise, that Sony 710 and its counterpart LiteOn 1633 give very different scan profiles at 6X and 8X speed, at least for some discs. The scans obtained with Sony 710 are more or less similar to those with Audiodev’s CATS. This phenomenon is the best example to show how firmware dictates PI/PO error counts. It also clearly explains the risk of using PI/PO error scans as indicator of writing quality without knowing what the numbers indicate. So it is better to use jitter for quality testing, as it appears not to be firmware dependent and even not very sensitive to scanning speeds in many cases.

[dolphinius_rex]

Yeah, but when you have a drive that normally reads +R/-R discs at say only 8x, over speeding is necessary. Otherwise they all look "good".

I do the same thing for our testing, but I have the read speed set at 12x, not 16x.

I also find that 12x is the optimal transfer rate testing speed. It seems to be a nice balance of speed:forgiveness for errors. 16x tends to be a little too hard to pass realistically on many drives.

[dolphinius_rex]

I can’t agree more with your comments. IMO, unless manufactures are willing to adopt a common way to implement PI/PO error detection, the chaos will remain. I have just noticed, to my surprise, that Sony 710 and its counterpart LiteOn 1633 give very different scan profiles at 6X and 8X speed, at least for some discs. The scans obtained with Sony 710 are more or less similar to those with Audiodev’s CATS. This phenomenon is the best example to show how firmware dictates PI/PO error counts. It also clearly explains the risk of using PI/PO error scans as indicator of writing quality without knowing what the numbers indicate. So it is better to use jitter for quality testing, as it appears not to be firmware dependent and even not very sensitive to scanning speeds in many cases.

Firmware can deffinately affect a drive's ability to scan a disc... but jitter is not the be all and end all of scanning either unfortunately. I've already noticed difference between how a DW1620 and DW1640 scan for jitter (the DW1640 is more forgiving, while the DW1620 is less forgiving).

Sadly, for a really good view of a disc's quality, the best way is still to test it on multiple drives. That way you can analyze several perspectives on the disc, and come to a more rounded conclusion. This is the basis for my own testing.

[vinnie97]

Sadly, for a really good view of a disc's quality, the best way is still to test it on multiple drives. That way you can analyze several perspectives on the disc, and come to a more rounded conclusion. This is the basis for my own testing.

so bring on the NEC error-reporting firmware. Talk about coming full circle.

[dolphinius_rex]

Sadly, for a really good view of a disc's quality, the best way is still to test it on multiple drives. That way you can analyze several perspectives on the disc, and come to a more rounded conclusion. This is the basis for my own testing.

so bring on the NEC error-reporting firmware. Talk about coming full circle.

Perhaps I should say:

Sadly, for a really good view of a disc's quality, the best way is still to test it on multiple drives (that offer repetitive and regularily consistant scan data). That way you can analyze several perspectives on the disc, and come to a more rounded conclusion. This is the basis for my own testing

How's that?

[RJW]

#3: ... there are too many people posting scans made on drives, making comments about things they don't understand, and have no intention of ever trying to understand properly. So many people have adopted error rate scanning as a way of testing media, without actually knowing how to use it effectively. I think it more people spent time looking at transfer rate tests it would be far more effective... or (more importantly), far less destructive! It's not hard to find a scan that looks good, even if the disc is bad... or vice versa. And a noob with only a tiny bit of experience and real information is a VERY bad combination.

So the longer NEC's can't do testing, the better, in my opinion.

I can’t agree more with your comments. IMO, unless manufactures are willing to adopt a common way to implement PI/PO error detection, the chaos will remain. I have just noticed, to my surprise, that Sony 710 and its counterpart LiteOn 1633 give very different scan profiles at 6X and 8X speed, at least for some discs. The scans obtained with Sony 710 are more or less similar to those with Audiodev’s CATS.

If I'm right there is a standard. The ECMA standards the ECMA clearly specifies how the device is build and what it should report and what the max values would be. What most folks did was just use the max values and allmost completely ignore the rest of the ECMA standards.

About Lite On and and SONY don't forget Lite On drives have variations itself. It's not the first time I see different results from a Lite On drive being the same model with the same firmware.
So It might not be firmware alone while the firmware also may have a significant influence.