sfbp

Start by setting disc mode to HiMD. You should have a lot more luck transferring Hi-SP and Hi-LP than the older modes, with a Mac. This because the HiMD support only reads files on the disk. The so-called NetMD support (actually it's really just "MD" support) needs drivers, and AFAIK they don't exist (mind you I don't know much, not being a Mac person). only for Windows. Your machine is defaulting to the other mode, either because you put a formatted "old" disk in when you do your recordings or because the default for completely blank disks is NetMD. The only way to get HiMD by default with your setup at the moment, without changing the setting is to put in a 1GB disk, since these are not backwards compatible with earlier units, and the RH1 does not need to support the NetMD/StdMD modes. But you should be able to change the settings on the unit to make yourself record in Hi-MD modes quite nicely, even with "standard" 80m disks. This is one time that reading the manual carefully will yield quite a lot of useful information. Welcome to the forums!

You're right, this isn't the right place for it. Better to buy (for $25) a drive that will read and write both DVD-R and DVD+R. Cheaper than 100 disks, probably.

Programs such as Nero which take full advantage of different advanced features of various optical drives will interrogate the drive and you don't have to worry. Sort of like Stuge said, but even more dynamic than that. Have you got trouble getting it to function? "Conventional" drives will have jumper configurations but this should not even arise in a laptop. If this is a second hand drive you may have a region problem. Typically the region can only be changed 4 times, and if your drive came from some other region of the world or was set deliberately to be :out of country: then you may not be able to play DVD's with the country/region encoding (most commercial DVD's). Won't affect the data abilities though. But since it is a ROM not a writer presumably you want it mostly for movies? You may have gotten a fool in tech support when you called them. I could be wrong, but oftentimes /x stands for a color. For example /s silver /b black /r red.

you said "transfer" (and before, u threw up hands saying you couldn't wait for x1 realtime recording). Best quality will be playback into optical of either unit. For this you need optical out or USB sound card ($15 will get you a nice one). Don't bother with analogue out, honestly.

yes, but the way the transfer works is to send LP2 and have the unit pad it with blank bits, so the quality is not as good as a "direct" record of SP. you have to use the option "SP Transfer Mode" in Sonic Stage - specifically designed for units which do not support MDLP.

ty for those insights. So, it sounds as if there are TWO sets of parameters that get out of whack with the laser. I will tell you the sequence that I think happens, because the whole thing mystifies me too. And none of my adjustments (touch wood!) have caused me to lose the ability to write perfectly good 80m disks. So I should be thankful for that. A. the unit recognizes a completely blank disk (more on this below). B. recording begins. This may be different depending on whether one downloads or simply recordings through the input socket (analog or optical). C. recording finishes, now it is time to finish off the disk (I may not have these exactly right but the spirit is there) i. encryption ii. table of contents iii. master checksum of some kind computed by the firmware. You can see this, if you change ONE byte directly in the files that have the music in, even if you change it back, the music will be unreadable. Clever, but bad, design, Sony, and I suspect one of the reasons they appear to have abandoned the format. Phase C takes reading. It is the READING that messes up, for whatever reason. In many cases I can make a perfectly valid disk readable by other HiMD units, that my OWN RH910 can not read. It can always read disks successfully generated by the other units. So something is "a little bit off" and it sounds like it is the same something on all these 910's, which is very very odd. My other 910 works fine, so it's not a manufacturing/software thing where some date ran out. In addition there are some very nasty things (possibly only 2nd generation units and RH1, I am not sure) that it does when you delete files on the unit. Even a "format" does not do a real format. Hence a "blank" disk is not blank. Here's what happens (maybe you or others reading this have seen this) when you introduce that disk to Sonic Stage: 1. A dialog box comes up which you need to click on (more bad design) that says "Checking for rights to recover from deleted files" or something close to that. 2. The top right hand corner area, which tracks transfers, now lists rapidly all the files that it is going through, "transferring" them. In fact what it's doing is to synchronize the rights in such a way that items with limited transfer count get credited back to you when a disk is erased by some means other than SonicStage. 3. This process almost invariably pauses at "66%" suggesting to me that it now does something different. I'm not sure what, but only the last file that used to be on the disk is now shown in the display at top right. This final phase seems to take a random amount of time. The key point is that it is trying to read information off a supposedly formatted disk. When everything works, clearly that's exactly what it does. You can also notice the amount of free space is less than 961.9 MB when there are lots of files that just got deleted. It's not until this "rights recovery" step that the free space is the full amount of 961.9 A completely blank disk never fails in this way. I can nearly always make starting with a 1GB disk, a nice disk that can be played anywhere (except sometimes this unit). I haven't rigorously checked 80m disks, but that's because I have yet to see a single failure. I'm running out of completely blank disks, so sometimes I blank them out by formatting and reintroducing to Sonic Stage using another unit entirely. To make a disk in this funny state (track ID's saved for later recovery) requires that the information be written somewhere for later reading. When this problem was worst (generally it is much better after my tweaking) the unit would hang up even "formatting" or "erase all" on a disk, with the message you have seen ("system file writing"). For some reason it's the reading back of this "invisible" information which is the problem. I have no idea why. It's almost like the disk develops a fault that causes the firmware in this particular unit a big headache. Please feel free to elaborate on this or correct any of it. Maybe if enough people make observations of fact someone may see the whole picture and figure out what's going on. I thought I did, that it was the laser power, but it seems more fussy than a simple adjustment. The weird thing is it doesn't seem to happen on my other HiMD units. Stephen

How's this for an explan: the CDDB was somehow getting confused and accessing D: just when the drive check should be popping up and accessing E:? But a very very interesting solution. Disconnect from the internet when you want to do a drive check. BTW, you can invoke drive check manually from SB, I discovered this week when I had a CDWriter go flaky on me. Maybe that's all you had to do. I noticed that CDDB cut in BEFORE I had a chance to press the button.

I currently **still** have the same problem. I actually thought I'd fixed it by adjusting the laser, but it seems that nothing is simple in this regard. Can you confirm that this ONLY APPLIES TO 1GB (HiMD) disks? So many people are having this problem I actually wonder if it might be common to all units. However I have an identical replacement unit that works perfectly, with no adjustment. Stay tuned, perhaps we may get some more input. I've adusted the topic title accordingly Welcome to the forums! Stephen

It will be an LP2 disk. LP2 plays as :silence: in an SP unit.

My sincere apologies for the random rubbish I wrote in the post which followed #18 (and subsequently deleted) and suggest you ignore it. Another day of experimentation (and finally checking against the values in my NH700) proved that all the values 9111 9112 9113 9114 all have to be reduced together as they all are functions of decreased laser power. IOW, the way to make the circuitry work is to cut back the laser power measured, so that the actual strength sent to the machine is higher, making the unit completely operable again. Original values: 9111 = 14, 9112 = 12, 9113 = 91, 9114 = A9 Final, working values 9111 = 11, 9112 = 0F, 9113 = 84, 9114 = 9F (these are the exact values in the NH700). If you do the math you will see these are about 15% smaller on average. The Docs say that the values for the first two measurements need to be within tolerance by 19.2% and 18.2% respectively, the 9113 by 12% and it completely fails to mention 9114. So it makes sense that reducing them all by 15% should be right in the ballpark to take them from not working to working I note in passing that all the embarrassing, nail-biting (is it going to crash?) delays are gone, and the unit absolutely shrieks along, as it should. I'm actually guessing the whole line was misadjusted, this seems to have been a common enough complaint that we have heard about it in different guises from a number of people. Stephen

just a quick word here - no experience with this line of players at all. But USB unstable may be exactly that. Try to a. eliminate all other USB devices b. clean up the USB device map (many many posts about this here) c. start using "Safe Device removal" religiously d. see if there is anything else using up vast amounts of CPU. A favourite current candidate is Firefox's "plugin-container.exe" from 3.6.4 and on which can use 30-80% of full CPU power. This typically does not bode well for USB devices which are even slightly time critical (and that is MOST such devices). Hope this helps... Stephen

Thanks very much for this. I think we should arrange to post the relevant files as part of a thread here so it doesn't get lost. (note to post author: sorry for giving you a hard time on this one). Stephen

It may be that every time a skin is changed the fix you made goes away..... Stephen (ie you may want to try fixing the template someplace)

Just a final word on this thread (I've been re-reading the current lore on this topic). I now believe that the rationale behind turning the read laser power DOWN is as follows: 1. The electronics in all MD-units is a complicated servo (i.e. feedback) system which depends on known power of laser hitting the disk at the right time and place. 2. When installing a new head, the laser power is measured under certain conditions. It is this power which is entered into the settings at 211(9111) and 212(9112), to determine how much power is required for reading. 3. When you "report" a larger number by entering it each of these locations (you will find that by design, 211 [expected power output based on actual characteristics of the head] is always a larger number than 212 [observed output power]) a smaller amount of power is actually sent to the head, to get the required output. And vice versa. 4. If you look in the service manuals for decks, the IOP value is a measured output of the laser head quite comparable to these two measurements. So REDUCING this number is INCREASING the actual laser output when it comes time to read the disk. In my case I had a problem with 1GB (HiMD) disks but (for me) 80m disks (at HiMD format) always worked perfectly. Avrin's observations happen to be the other way around. I have no clue why that should be so. I may still have some problems, but at the very least I am always writing disks perfectly now. Odd that changing READ parameters should make a difference to that, but my rationale is that it is when the unit tries to re-read the TOC to finalize the directory of files that the problems occur. It is still quite possible that some other parameters need to be fiddled with when these units get in this (general) state. I am still resisting buying a Laser Power Meter, but one of these days I may break down..... Happy tweaking! Stephen

That is correct Did I not mention that? Stephen

I think I finally got to the bottom of this one, three years on. INCREASING the setting that Avrin refers to here (post #20 above) and in several later threads on the forum indeed increases the write power. Unfortunately I have discovered that the problem is that the READ power is at fault. Typically what happens is that the unit can write all it wants until it needs to re-read the TOC and enter the new files into the directory. At which point it fails with a rather unexpected read error. The way to get this read error to disappear is to increase the read power. However to do it is sort of counterintuitive... you have to DECREASE the measured laser power (which corresponds to the laser itself aging as you might expect) so that the circuit pumps out a bit more juice to drive it hard enough to read properly. The key numbers on my RH910 were 14 and 12 at 9111 and 9112 respectively. I changed them to one less, 13 and 11, and perfecto! or Bob's your Uncle, as they say. Just thought perhaps appending this comment here might help to put this into context. It seems that this problem has been with the 2nd generation units for a long time now. Stephen

Jim, I just figured out how to fix the problem we both seemed to have (your symptoms were almost identical to mine). After months of puzzling over it, the solution was very simple - reduce the main Laser READ power (both measurements, ref and actual) by one notch. In my case 14->13 and 12->11 (Hex as it happens but who cares?). I learned this trick because of an experience with a deck that had somewhat similar problems - could write perfectly but not read what it had just written. Stephen note: "reducing the laser power" is actually a mis-description. The numbers in question purport to measure the output of the laser under specified test conditions. So presumably LOWERING the measured numbers means the circuitry will compensate by RAISING the output power a little bit when accessing the disk surface. What we have done is to turn up the gain.

See post #20 in this thread. To get Media Player to be the default player for OMA or oma, AND this extension show up in the list of files it offers to open for you, you HAVE to alter slot 1 as Avrin describes in HKLM\Software\Microsoft\MediaPlayer\Player\Extensions\Descriptions and in HKLM\Software\Microsoft\MediaPlayer\Player\Extensions\Types Nothing else will actually do it. This has been bothering me for weeks, and I finally woke up in the middle of the night and re-read everything and solved it. Note, on W64 the same stuff is all under the "backwards-compatible" section of the registry that is at HKLM\Software\Wow6432Node\Microsoft <blah blah> Stephen

Hooray, that means that almost nothing is wrong. I'm unfortunately not an expert at fiddling with the pieces of the SonicStage install. Avrin seems to be the only one. What I strongly recommend is that you simply install his Ultimate edition over top of what you have and see if that helps. I have done that without problems. The pieces are quite complex and the encryption/decryption stuff is very well hidden in an interpreted language (bytecode) subsystem. I never asked what version of Windows you are running. If you are on W64bits there are all sorts of possible "gotchas" which I can think of. But others got it working (I don't have W64). If the .OMA file still won't play it sounds like the codecs are simply not installed. Could that be because of W64? Stephen addendum: I recall something about Microsoft ADPCM Codec needing to be in the list of Codecs (at CtrlPanel->Sounds and Audio Devices->Hardware->Audio Codecs->Properties, at least in Windows XP) and somewhere near the top of it, and not disabled. Maybe it's as simple as that? Did you recently install something that plays HDCP/HDMI? Whoops: you might have to enable the "Microsoft PCM Converter" too, see this post by Avrin

To cut a long story short, let's see if the DB is intact by running the File Conversion tool and removing the decryption. This is accomplished by unchecking the box "Add copy protection" that you get at the second screen of that utility, before proceeding. If all goes well, at the very least you now have hi-SP files you can copy to another installation and play there. Can you try that and report back? If it works, the filenames should change from .oma to .OMA, incidentally, though this suffix (.OMA) is NOT an infallible indicator that a file is decrypted or encrypted. S

First step is to show the "file path" on the list of attributes in my library. You may find the file isn't where SS thinks it is. Another thing you can try is to FIND the file (using Windows) and open it with Windows Media Player. Once you have found the files, it might be a good idea to decrypt them. But you have to find them first. If you know where they are but Sonic Stage doesn't, you can delete them from SonicStage without deleting the actual files, then re-IMPORT them to SS. If you need help with any of these tasks, just yell loudly..... You'd better tell us exactly what error you get. It's possible that you tried to play back the files on a different computer or different Windows installation without decrypting them on the old one. In this case, you HAVE to go back to the old setup, or reupload them using the new installation, from HiMD. Stephen

yup

I agree. The manual for the E35 shows a unit that doesn't remotely resemble this, however. So either the manual was thrown together (odd because it is dated 1998) badly, or the unit never made it past the promotional ads. Presumably the picture you posted is a "real" one from your friend, so it's the manual which is wrong. This is the earliest mention I have so far seen of the gumstick battery style. Not that I have actively looked, I just don't know exactly when they were introduced. Stephen

A while back I got SS version V working. Look at the original post(s) by Avrin. It involved several elements. One was installing Jp support and the language bar. Another was applocale. Interestingly, although Japan is removed from my options with the language bar, SSV still runs (I just checked). However my Japanese is nonexistent, so the result isn't much use to me. I suspect that applocale is the key; if I wasn't somewhat preoccupied I would have made the effort to try it. Stephen PS note that I do NOT think that this software *is* SonicStage. I think it's something else, and that's why (at least initially) I haven't bothered. Old dogs, new tricks.......

The proportions look a little strange... all the MD units around then were wider than that appears to be. Assuming the picture got a little distorted, I would say, if it's really a PLAYER then it looks like the MZ-E40. If it might not be a player but could be a recorder, it looks quite a bit like the (portable part of the) MZ-R4ST.