dex Otaku

Before I say anything else: if you have the means to do so [i.e. internet connection], upgrade your SS to 3.4 immediately. Before you do ANYTHING with that disc, eject it from the recorder, unplug the recorder from USB or AC power, and remove the battery. Leave it that way for about 30 secs, then put the battery back in, and re-insert the disc. See if it still comes up with the error. If it doesn't, great. If it does, your recording is gone and reformatting is your only choice to reuse the disc. If the disc were damaged by SS crashing during a write operation, then it's not completely erased, but the structure is damaged. See next answer. Well. This depends on a number of things. I personally doubt there's any actual damage to the disc at all, but we'll get to that in a minute. Generally speaking, since HiMD's audio functions use a closed [proprietary] system, and since Sony has not released any data-recovery tools, there is no way to recover any data from even minorly "damaged" [data-wise, not physically] HiMD-formatted discs. Anyone wishing to write recovery software will have to liscence the info from Sony, and given the size of the HiMD market, I sincerely doubt the likelihood of that ever happening. No, it's not your fault. Or, well, that could be debatable in a certain sense: if you had lots of other programs, USB utilities, &c. running while SS was, then you can kind o expect reliability to take a nosedive at some point. The same applies for almost any software, mind you. I wouldn't call that the user's fault, though. Yes, it's happened to other people. The exact symptoms you've described actually sound most like the issues surrounding uploading tracks with known write errors in SS 3.3 and earlier [which I have experienced myself; SS 3.4 appears to handle this issue vastly better than previous versions, btw]. Yes, it could happen again. Upgrade your SS. The improvements regarding uploads and DRM alone are worth it. SS 3.2 introduced unlimited transfers of self-made recordings, for instance; with SS 3.0 you only get one chance to upload your recordings. After that, attempting to do so again will simply erase the tracks. It's likely that yes, it will. There's a small chance that the problem you experienced is related to something else completely, though, such as SS interacting poorly with another program running in the background.

SCMS may be silly, but when properly implemented it works. It allows for fair use rights, while limiting the propagation of copies, assuming that a "stripper" isn't inserted in the duplicating chain somewhere. Point being: SCMS isn't at fault here. BMI's abuse of it by breaking the rules clearly is. Er.. EMI, not BMI. Heh.

This could be a mistranslation or poor communication issue. I have had Koss products serviced at >10 years of age with no problems. There are some things they don't cover, though, including worn-out cables.

Additional note: If your system really does have USB 1.0 [as a P-III it's far more likely to be USB 1.1] then.. well, here: Rated speeds - USB 1.0 - 1.5Mbps USB 1.1 - 12Mbps USB 2.0 - 480Mbps If it really is USB 1.0, that might be another factor. I would point out, though, that legacy MDs [MD60, 74, and 80] as used by netMD have peak write speeds between 1-2Mbps, and read speeds around 4Mbps. Since netMD is download-only, using it with USB 1.0 isn't likely to cause any kind of really dramatic slowdown compared to USB 1.1 or 2.0.

Good examples. [not sarcasm] Don't get me wrong. I'm not supporting "their side." I'm just saying - there are certain uses for "calling home" which don't imply potential abuse. It would be awfully hard to abuse Gracenote's access info, for instance. It's great for compiling statistics about what gets listened to most frequently on computers with CDDB access, but otherwise? We don't really know what SS sends out, do we? Does anyone want to invest the time into packet-sniffing all of SS's traffic to see exactly what gets sent out? I'm curious, on one hand. On the other, I expect the information to be so completely innocuous as to make any privacy concerns superfluous. Even the rootkit scenario worked the same way. The player module would call in for advertising, to check versions, &c. [this has been verified by all an sundry]. Pretty damned innocuous, even if it was "under cover." But wait - they can match all that info to specific people! Even if the user registers with false information [noting that SS never asks for personal info, though it could cull limited such from Windows itself], their accesses are idendifiable by IP address [assuming they're not using anonimising proxies]! Oh no! What SHALL we do? They can subpoena our ISP's records to check who was on that IP at that time and get our name and address! Oh dear! Most people don't even realise that basically every web server on the planet logs every access made to it. The standard information collected includes the requesting IP address, browser type, referring URL, time and date, and more. I have been using exactly this system to track who reads my blog for 4 years, and while the information is often ambiguous at best, patterns do pop out that can reveal exact people reading pages from specific locations. That's without using cookies or authentication of any kind. Thing is, I actually read and analyse my logs. Millions of websites don't do so. The information they collect with every single access gets used for statistical and sometimes diagnostic purposes, and that's it. At least.. until the FBI or RCMP or whoever ask them for their server logs. You want paranoia? How about Google or Yahoo tracking every search you've ever made? My real point here is not that privacy is unimportant - it's that the situation has already gotten so out of control. The cat's so far out of the bag that the bag doesn't remember having a cat in it. Our data is out there. Period. Every single place we visit on the web, every service we use with almost any protocol, is logged. When it comes down to it, the only safe way to use the net is not to use it [to paraphrase Einstein, if I'm not mistaken].

Last I read, OLED is no more efficient than LCD, but more efficient than LED. The real reason to use OLED, though, is that you don't require a backlight as it's [obviously] self-emitting. LCD+backlight = less efficient than OLED. There are advantages and disadvantages to both. OLED can be hard to see in direct sunlight, as can colour [almost always backlit] LCD [more intelligent designs will let you turn off the backlight and have a "lightpipe" that uses ambient light to backlight the display instead]. A more major difference though, IMO, is that OLED will work at pretty much any temperature, whereas LCD's characteristics change dramatically, including contrast change and "speed" .. try using an LCD at -20C and you'll see what I mean. You have to actually wait to the display to catch up. One thing to say about touchscreens: look at Sony's current line of consumer video cameras. 5 years ago I would have recommended a Sony video camera to anyone [having used them and others since the early 1980s] but now.. not a chance. Their entire current product line uses touchscreens. Why is this a problem? Let's say you want manual exposure control - have to use the screen. Manual focus? Use the screen. Play controls? Use the screen. &c... Now, try to imagine doing handheld shots where you don't want to stop the camera in order to tweak a setting. Try to imagine the difficulty in holding the camera still -and- keep your eye on the shot while having to go through menus and settings on the touchscreen at the same time. It's next to impossible. I know several people [including a college department who bought a caseload] who subsequently returned their newer Sony cameras because the interface hindered their use so significantly. No, with HiMD and MD we don't [usually] have to worry about holding the unit still to get a good recording, but it's just an example of how applying one interface in favour of another [touchscreen menus over actual buttons] can lead to unforseen problems when actually using the equipment. A parallel example of this was the move from switches and buttons to menu-driven interfaces. Which would you rather have? Instant access to exactly the control you need, or only one control and having to waste time navigating options [sometimes only to be told that "you can't set that" because the unit's in record or not]? More than that though is the fact that their touchscreen controls, i.e. the interface design, is absolute crap. A lot of us complain about the quirks of having to use the menu interface on current netMDs and HiMDs. Given Sony's track record with touchscreen interfaces, imagine the existing menu quirks amplified about tenfold, and you'll see why I'm firmly against the idea. That's not even mentioning what you already did - not being able to use the controls blind, like reaching into your pocket, finding the play button, and knowing you pressed it. Tactile feedback is a valuable thing. I wish they'd go back to actual buttons and switches, and ditch menus for most functions altogether [keeping menus for things like titling, perhaps]. I liked being able to hold the record button for 2 seconds of the MZ-R37 in order to put it in manual levels mode, for instance. Or being able to turn the unit over and change the mic preamp's sensitivity or AGC mode simply by flicking a switch while the unit is still running. Or, for that matter, when it's not. Unicode is definitely compelling, but there's a reason to stick with smaller character sets. As an examplex compare the TrueType files for Arial and Arial Unicode. Arial: 335kB / Bold: 282kB / Bold Italic: 222kB / Italic: 203kB Arial Unicode: 23,566kB While low-resolution bitmapped fonts are much smaller than TrueType fonts, the scale issue still apllies. I think that pretty swiftly explains why they don't use it.

We don't have all the answers. Sony don't have all the answers. There are literally millions of possible configurations under which SS could be running. It's impossible for us to know the exact conditions under which you experience your problem. We are not sitting at your computer, knowing what your hardware is, knowing every piece of software you've installed, and knowing how you've configured everything. All we can do is take whatever information your give us and do our best to match it with known problems. That said, your patience would be appreciated.

It's called SonicStage, which is what OpenMG Jukebox was renamed to some time ago. SS 3.3 or 3.4 is available from connect.com, depending on your area. They may all be up to 3.4 by now. Anything you send to you netMD has to be encoded or transcoded to atrac3 in order to work. Encoding takes time, and the slower your computer, the more time that means it takes. If you keep a library of already-encoded tracks on your computer with SS, you won't have to go through the wait of encoding/transcoding every time you download - it just downloads the already existing copy. When you rip CDs, SS will encode directly to whatever atrac3/plus format you choose. Note that your netMD supports only LP2 and LP4 modes, AKA 132kbps and 66kbps. That said, if you don't change the contents of your MDs very often, Simple Burner is much better for sipmly ripping CDs directly to netMD or HiMD. Ripping CDs with SS means always having those tracks taking space on your computer. SB doesn't store anything on the computer, it just encodes and writes to your netMD. If you try to download MP3s, they also have to be transcoded [converted]. If you're trying to download MP3s and are getting silent tracks as a result, you probably have a misbehaving or simply incompatible MP3 codec installed on your system. If you have ever installed codec packs of any kind, they are a likely source of misbehaving [not to mention outdated and just plain broken] codecs. I would suggest browsing the Software forum here. There are numerous threads about MP3-transcoding related issues, and many of them contain solutions. And yes, most of the problems do revolve around bad codecs. Lastly, your problem -might- just be solved by upgrading to the newest version of SonicStage, though I can't predict the likelihood of that. That would be the first thing I'd do in your case, at any rate.

This may be true, but as soon as you've done this, you'll have to re-format the discs either in SS or on the unit itself anyway. If you format the disc with either SS or the unit itself, it may only erase the TOC, but that's all that's really required. The data from previous recordings still on the disc is irrelevant at that point - recording something new will not cause fragmentation [since according to the TOC there's no existing data to fragment around], and the erase-cycle and amount of power it and writing new data consume are the same whether the disc is fresh from the shrinkwrap or has been written to 1,000 times and reformatted by the user. My point is, basically, what you're insisting on is completely unnecessary, and actually adds another step to the process since you'll have to reformat using SS or the unit in the end anyway. If your concern is based on .. well, security of some kind, like if you recorded tapped phone conversations between some senator and a terrorist, then I'd suggest doing a format on the unit, followed by setting the unit to record in PCM mode with no input. When it reaches the end of the disc, it will have erased all previous contents completely. Of course, you'll also have to reformat it at that point to use the disc again. I say this because to the best of my knowledge, no existing forensic data recovery software is capable of reading previously-overwritten data on a HiMD or even legacy MD. Magneto-optical discs *should* experience complete erasure during the erase/write cycle, unlike magnetic media which can retain "layers" of data post-erasure and post-write, hence the "need" to do multiple random or patterned writes on hard discs to ensure their contents are actually destroyed. If you're really paranoid about the previous contents of an MO or MO/DWDD disc, then you should destroy it by fire. In the meantime, I would suggest simply using SS's initialise function or your recorder's FORMAT fucntion to erase your discs. Either will do what you require - leave you with a blank, unfragmented disc. Hence the words "initialise" and "format."

1) CDDB and the backup tool require 'net access to work. Without access, you will not be able to restore backups, as the tool checks your rights info against something on the net. If you don't mind having to title all non-CD-Text CDs manually, and not having any means to restore backups of your library, feel free to block SS's traffic, or for that matter unplug your net access, or just don't plug it in in the first place. 2) ... I know everyone gets all worked up about privacy issues and apps that "phone home" .. but really, if it's either a) checking for updates, or getting CD info, and even if in either case it's recording those accesses .. I simply don't care. I expect some of the program's functionality to use the net, and the only obvious things it's doing are the two above [other than the backup tool doing rights checks].. Do we really care if Gracenote [not Sony] know every single CD that one installation of SS on our computer has seen inserted? Should we be more or less concerned by the fact that FreeDB works the same way, but is not run by a single corporation? Do we really think Sony are combing through millions of system configs supposedly reported by SS around the world looking for .. what? Really, what? Do you honestly think that SS, which is individually keyed by installation [i.e. identifiable as belonging to one customer or rather as being installed on one computer], is reporting anything even remotely useful to Sony? Do you think they actually give a crap about what video card and driver version you have installed? Do you think they even use *any* of the information that could easily be culled from every single one of our systems? And lastly, if they chose to use it, what do you think they would use it for? To blackmail user X because they use the wrong sound card? There's a fine line between paranoia and stupidity. Further, we said YES to the EULA whether we read it or not.

Yes, this isn't often mentioned here, but the backup tool backs up EVERYTHING in the library. Workaround: Keep only your OMA [atrac3/plus] tracks in the library when backing it up. It's much easier to re-import your MP3 collection after doing a reinstall/restore than it is to sit and wait while the backup tool copies every MP3 in your library. Easiest way I've found to do this: * In "My Library," switch to the "All Tracks" view. * Right-click on any column header in the window, and enable both "Format" and "Codec" * Click on the column header for "Codec", sorting the entire library by codec type * Select all non-ATRAC3plus tracks and hit delete [make sure you do NOT check the box on the confirmation dialogue for "Delete this music file from my computer"] Notes: The reason I turn on both Format and Codec is because PCM tracks can be either OMA or WAV in the library. Generally speaking you WILL want to remove WAV files from the library, and NOT want to remove OMA PCM files [like uploaded HiMD recordings]. Once you've removed all non-OMA tracks from the library, you can run the backup tool an rest assured that ONLY the files actually created by SS will be backed up. The difference between my doing this and not with my library is currently about 26GB, so you can see why I do this. edit: BIG error there: * Select all non-ATRAC3plus tracks and hit delete [make sure you do NOT check the box on the confirmation dialogue for "Delete this music file from my computer"] is completely wrong. It should read: * Select all non-OpenMG Audio tracks .. Yeah. And for that matter, sort by Format, not Codec, and all the OpenMG Audio tracks will group together, letting you select everything else even more easily. Oops.

It probably is, yes. The version in the dl section is the most recent Asia/Pacific release, which supports PCM downloading to HiMD. Sony have not updated SB to reflect the recently added support for other bitrates with HiMD. Hopefully they will do so, especially since it should only be a simple matter of updating the UI to add the new rates.

note: I was assuming that the AAC files are NOT carrying Apple's DRM.

AAC = Advanced Audio Codec, basically MPEG-4 audio. This is the format that iTunes prefers to use natively. You can convert AAC files with dBPoweramp [in the downloads section], foobar2000, &c. Suggestion: if you want to get those AAC tracks into SS, don't transcode them to MP3 [another generation loss] followed by converting them to atrac3plus [another generation loss]. Decode the AACs to WAV and then use SS to convert to your destination format, or use Windows Media Player [if it will play the AACs] to convert to WMA lossless [smaller files, no loss in quality] which SS can also convert from directly. As I have never used WiMP for such, I can't give actual advice on how to do that. [i actually don't use WiMP at all.] Others here have done this and can probably lend you advice on the subject, though.

I have logitech z680s. The lack of any EQ whatsoever is painful. A subwoofer level control is NOT adequate to compensate for extreme resonances like the +14dB @ 105hz in my living room. With the sub control alone I can either choose to have actual bottom end with ~100Hz so loud that things rattle off shelves, or no bass whatsoever. PITA.

Hmm. There are some surprisingly nice skins there .. I'm really into minimalism most of the time; i.e. a mini-player should be the controls and the most basic play info, period. Those teeny ones that are about the same height as a title bar are really quite functional. Now if only SS had built-in EQ and support for any Dshow-supported audio format the user has codecs installed for. As it stands, I don't even use it for playing OMA files [i use Media Player Classic with its basic playlist]. I suppose when it comes down to it though, the -only- reason I won't consider using SS as a player isn't because my library is only 50% comprised of MP3s; it's because the acoustics of my living room/studio *REQUIRE* EQ for resonance correction.

It's interesting to me how .. different people, because they use MD or HiMD differently, find different bugs in the firmware. I have never experienced any editing bugs with HiMD simply because I don't usually use its editing features. This probably comes from a tacit philosophy of mine: never edit the master, or for those less hardcore than I, never edit the master until it's been duplicated. Of course, once it's been duplicated [i.e. uploaded], it's far easy to edit on the computer than on the recorder. As a result, I never find the editing-related bugs.

Yes, things have changed. As recently pointed out in another thread [not by myself] you can select uploaded tracks in your SS library, right-click, and choose "Convert" from the context menu. If you choose the same bitrate as the file was originally in, and uncheck the box to "add copy protection", SS will create duplicates of the tracks without DRM on them, and without transcoding them [no further loss]. The files will show up in a folder inside the main SS library folder called "optimized files". You can copy the files from that location and name them as you wish, by utility or not. These should be safe to copy to CD- or DVD-R and can be copied to and used by any installation of SS. Cheers.

Indeed, another case where it needs to be updated. I had not actually tested this with SS 3.3, and left it as it was [which is now incorrect]. Thank you for the heads-up.

I've found reporting of this to be very inconsistent. Some SP/DIF inputs on sound cards will allow anything to pass [sCMS ignored]; Some won't allow anything to pass except for "monitoring" [using the sound card as a DAC]; and Some respect SCMS. If you are looking at a sound card or USB adapter with SP/DIF inputs [optical or coax], I'd suggest searching the net for tech and customer reviews of the units you're looking at first. Also, reading the full specs or operations manual of the product will sometimes specify how it deals with SCMS.

For under $100, one can purchase USB sound adapters that heve 24-bit/96Khz DAC and support 6 output channels [for 5.1 audio] as well as having a stereo line input. Since they are designed to be powered by USB, they can have full line-level outputs and some even sport half-decent mic preamps. Most also will work at any sampling rate between 8-96kHz. By contrast, MD and HiMD portables work only with 16-bit audio [though the ADCs in HiMD units are 20-bit]; they are locked at 44.1kHz for playback; no current models have an actual line output as they are designed to run from a single 1.2V NiMH battery.. &c. To have full function as a USB sound card without compromising the sound quality of any non-44.1kHz stream sent to them, they would need: * to support a full range of sampling rates for playback [i.e. not to resample everything passing through] * to support higher bit-depths natively for playback * a redesigned power section with output amp made to support full line-level [which would likely also mean increasing the number of batteries req'd to run the unit or deciding to go only with at least 3V lithium cells], not to mention higher power to handle less-efficient full-sized headphones To put it simply, a USB sound adapter and the output section of any netMD or HiMD unit are not equivalent to each other. They could perhaps include this functionality in future units but IMO, even if it's possible, to enable such on older and present units would be a waste of time. This depends on where you are. Very few people where I live have ever heard of or seen MD equipment, including employees on audio/video shops, local broadcasters and/or reporters, police, &c. When shown the recorder or discs, and informed that the format has been around for 14 years [and basically took over in Japan for a long time], they usually stammer incoherently.

Well, no. I find that the default naming scheme in SS is not always the most intelligible one to use though, especially if you're exporting as WAV and converting between other formats in something else. For lectures, I would be bound to use a variant of my own naming scheme: year-month-day - lecturer [or lecture title] - track# in that lecture Which for the April 24, 2003 Barbara Frum lecture by Bernard Lewis, would end up like this: 2003-04-24 - Bernard Lewis-What History Teaches about Islam - 01 .. 2003-04-24 - Bernard Lewis-What History Teaches about Islam - 02 .. &c. [whether to include more full info than this is up to you, this is how I would likely shorten lecture names] By no means am I saying this is the "right" way to do things, either, it's just one of many possible ways. What's best for you depends on how you like to organise things. I like things to be immediately obvious as to what they are by filename/containing folder. Read it once, you know -exactly- what it is, when it was from, who it's of, what part it is, &c. Using filenames that are way too long can run into problems, though, so abbreviations and choosing only the most pertinent info to include in the name is important. Files when written to Joliet [iSO or UDF] CD-R or DVD-R are shortened to 64-character names, for example. The real advantage of titling on the original disc first is that when you upload it, the filename SS uses will be the title. When you export to WAV, the title passes on as the WAV filename. Trying to guess tracknames when making mp3s of it is unnecessary because the track titles are the filenames and contain all the pertinent info needed for tags already. Programs that can intelligently create tags, like foobar2000 and MP3BookHelper, can be told how to read your tag format and convert the filenames into full tags in a single step, as well. In the end, it's optional, but I feel that titling at the source before uploading means less possible confusion later, especially if moving between different file formats.

Not from plugging it into it, no. What I mean is if you have the recorder sitting directly over a large unshielded power supply transformer, say - that's when problems could potentially arise. Most audio equipment is made with at least modestly-shielded PSUs and transformers, so the likelihood of this happening is pretty damned low, but you never know. I did once experience a problem with a recording made on a R-70 that was sitting on top of a TV set, for instance. There were dropouts throughout the recording [as well as audible noise] that I could only guess were caused by the TV's magnetic fields..

I've left MD and HiMD recorders on top of the effects rack many a time and never experienced any issues, but yes, vibration can be a problem.. Also, if there's a power-filtering system or anything that might have very strong magnetic fields around it near where you place the recorder, it could potentially interfere with things.

Let's repeat all the same questions then, shall we.. * list your SS module version #s from the "about" box * what is the source of the problem tracks? MP3, WAV, ripped CD, other? * does the problem occur at all a3/+ bitrates or only with [a] specific rate? If so, what rates? * could you please encode a track without copy protection [do it with something public domain or CC], verify that it has the problem, and upload it for us to hear? * as a suggestion for what to encode and upload: get a test file of white noise or a tone sweep; while these can't show every defect, anything severe that is going wrong during encoding will usually be immediately audible [and visible] this way