dex Otaku

Oh, geez. [slaps forehead repeatedly]

I recommend the 57 [and and its little-brother model, the 37, for the following reasons: * durable metal case * record/option controls are switches and buttons, rather than using menus * manual level control can be enabled without using a menu * they use AA batteries [2] * actual line output, not just headphone out My friend still uses her MZ-R37 for stringer/freelance work, and compared to either my NH700 or RH10 it is built like a tank, and with the exception of titling and editing, its controls are much more direct-access and easier to use than any of the current generation. If they would take an R57 or R37 case and put HiMD guts into it, I'd buy it in a second.

Could you possibly record, using your computer, the playback of your 910 so we can actually hear what the problem is?

Given that you can exchange tracks of almost any format, I'm assuming that 100% of the users you're exchanging with are also HiMD owners, in which case this makes perfect sense. Having just tried this myself, I must say that I'm extremely surprised to find that indeed, no re-encoding takes place when doing this; SS creates an exact audio-duplicate of the track which is stripped of inhibiting DRM in the "optimized files" folder. I'm totally stunned now. Do you mean like radio dramas? I engineered one of those myself a couple of years ago, it was honestly the most interesting work I've ever done. I grew up listening to a number of similar kind of projects [from Danny Kaye reading Hans Christian Anderson and "stories from other countries" to mysteries and ghost stories for children presented by Alfred Hitchcock]. I wish I could get my son to take an interest in such things, I'm sure by the time he's a teenager things like the Hitchhiker's Guide might make him laugh.

The DRM info is carried on the disc itself; when you uploaded the tracks the first time with an older version of SS, it automatically changed the info about the tracks on their original disc to say "I've been uploaded, don't allow me to be uploaded again." At this point in time, Sony's DRM is uncracked, so no, you can't change or simply erase that data.

This sounds odd. Are you certain you have sufficient disc space to export the track? I have successfully exported tracks in excess of 1GB in length [from HiSP sources, they being less than 1GB of course]. Versions of SS previous to 3.2 would update the DRM info of uploaded tracks so they could not be uploaded again. If you uploaded the tracks with a version of SS previous to 3.2, you will not be able to upload them again using any version of SS. Despite what some users have said about using HiMDRenderer, it will not help in this case as HiMD tracks have to be in your active SS database [i.e. already uploaded] to be converted with it. There are alternate methods of copying the audio from those discs, though. Please refer to the HiMD uploading FAQ for info on analogue and digital copying methods, using Total Recorder for example.

It's true that this may work, but I question why one would want to do this. First, you can export as WAV or use HiMDRenderer. This is one way to free uploaded tracks of DRM. Second, re-encoding the track immediately adds a second generation of loss to the recording. Third, if teh destination is another HiMD, you can write it back to disc anyway, regardless of the DRM. Also, regardless of whether there's DRM on it or not, you can't copy the tracks off another HiMD anyway, making the DRM issue completely irrelevant in that case. If what you want is a redistributable format, using atrac/3/plus [even without DRM] is limiting your audience to people already running SonicStage. If re-encoding is being done specifically to "unlock" the files, then moving to another, more open and more commonly-used format would seem far more practical, whether that format is lossy [still incurring a 2nd generation of loss] or not. To me it's an interesting exercise but not one with any really practical outcome. My question is what your intentions in actually doing this are?

I would like to point out that the reason members here constantly point to MD/LP recording as not being uploadable via USB is that the assumption is made [as is correct nearly 100% of the time] that people are asking if such can be done with common, consumer equipment - specifically netMD and HiMD portables. I too would like to see HHB produce a HiMD portable with prebuffering, phantom power capable XLR mic preamps, SP/DIF in and out, &c. That Sony won't allow uploading from MD/LP discs in this day and age is basically a matter of throwback. I personally wouldn't care if PCM conversion is a certainty in the process, simply being able to copy legacy MDs without having to go through at least one generation of D/A and A/D conversion [or buying a deck with optical out and sound card with optical in] would be boon enough to me.

I stand corrected. Partially. Converting from any lossy format to an uncompressed one completes one generation of loss from the original source. It can be considered lossless compared to the [lossily] compressed format that it was stored in.

1st-gen recorders also record in true SP mode, in real time, via analogue or optical in. Note that this only applies with legacy MDs, with the unit in netMD mode. The same applies with LP2 and LP4 modes in realtime. SonicStage can write to either HiMD or legacy [neMD] mode discs in true LP2 [132kbps], LP3 [105kbps] or LP4 [66kbps] modes as well. There is also a compatibility mode that writes pseudo-SP, which is LP2 padded out to fit the SP data rate, which means you can play it on older legacy decks [such as in your car] but the quality is only that of LP2. Pseudo-SP mode is available only to be written to netMD-mode discs.

My guess is that they are probably rigged in parallel, which would mean the dry cell attachment would indeed put current across the NiMH cell [and vice-versa]. As I have tended to avoid using the USB charging method, this hasn't been altogether relevant to me - but it goes to show that reading the manual can provide useful information. In practise, I almost always use either only a fresh AA dry cell or a fresh dry cell with fully-charged NiMH gumstick when recording. In combination, the total battery life [even with generic AA alkalines from bulk retailers] exceeds 8 hours recording time at HiSP [256kbps] with a HiMD disc [which consume more power for writing to than legacy MDs]. In this fashion I have successfully made test recordings to HiMD that completely filled a 1GB disc at HiSP [7 hours 54 minutes] and still left sufficient charge to write another complete MD80 [formatted in HiMD mode] also at HiSP [2 hours 23 minutes]. Your mileage may vary, of course. In the end, with some care the gumstick batteries give decent performance and life if properly cared for. The use of HiMD recorders' "quick mode" et al [which incur a constant low-current drain on the batteries in order to maintain disc memory] might also help maintain rechargable batteries by exercising them. I have no complaints about the performance of my RH10 with the gumstick, even if I do nearly always use the sidecar when recording. Added note: I've also had somewhat contradictory answers given on this. My understanding was that with some older models that used a sidecar, the internal rechargable was actually -charged- by the sidecar battery, and that the gumstick has to be inserted in the unit for the sidecar to work [whether the internal is fully charged or not]. Others have said that this is not the case. The RH10 [the only unit I can speak from experience on] can be operated successfully with the sidecar alone and no gumstick present. I could dig out the manuals for all units with sidecars, but in all honesty, I simply haven't the inclination to invest the time just to answer this question. I'm certain that what applies to the RH10 also applies to the RH910, since the only apparent difference between them is the display.

NiMH batteries do exhibit the 'memory effect' over time, though substantially less so than NiCd cells. I tend to take the NiMH battery out of my RH10 when plugging it in via USB, unless the battery is fully dead and I know I will be leaving it plugged in that way long enough to recharge it. For more complete info on battery types, see http://www.batteryuniversity.com/

To elucidate slightly on what raintheory said.. Legacy MDs can be used when they are formatted in HiMD mode. One MD80 holds 291MB. The magneto-optical media used by HiMD and MD are too slow themselves to require more than USB 1.1 speeds. The write and read speeds are physically limited by the medium. See http://www.minidisc.org/hi-md_faq.html#r_q104

And what: Sony are bastards on this count, like so many other corporations, who take a consumer device, make one tiny change [oh, and some cosmetic ones, sorry] to its internal software, and then charge more money for the same thing under the veil of calling it "pro". It's utterly stupid on their part. What I'd like to see is someone take the mac software and crack it so it will work with any HiMD unit, at least with PCM uploads. The VirtualPC route has been flogged to death already in other threads; the conclusion was basically that it can work, but that it's so slow that it's unusable.

The only difference is likely a USB deviceid or somesuch, that the mac software uses specifically to identify the unit as an M model, rather than an RZ model.

While the software for mac is freely available, but the RH10 itself is not identical in hardware to the M100. The difference appears to be in firmware only, allowing the mac software to recognise the units. So no, you can't save money by using an RH10 with the mac software. Which, in all honesty, is completely ridiculous, bordering on criminal, IMO.

d'oh! [and I've even used it myself! I should know better!]

I stand corrected. I was under the impression that editing was only for files that had been uploaded. That assumption meant I've never even tried with anything else.

It's a semantic thing. Decoding [of lossy formats] implies that it's been encoded [lossily]. If it's been encoded [lossily], there's been a generation of loss. "Lossless" copying of lossy data means keeping the data exactly as-is, which means no decoding takes place so no further generations of loss are incurred as long as the initial [lossy] encoded track is the only thing transported from one medium to another. At this point, there is no way to move MD or MDLP tracks to another medium without decoding them, completing at least one generation of loss [which in many if not most cases will be re-encoded lossily once again, adding a second generation of loss to the chain]. Hence my referring to decoding as a lossy process, not because it's inherently lossy, but because it completes a generation. There is one exception to this, those data drives that copy tracks directly, though in that case the resulting tracks can only be copied back to another MD; no other device or medium [including the computer the tracks are copied to] can accept or manipulate those tracks without also decoding/transcoding them in some way.

I couldn't be certain, to be honest. The only way to tell if it's actually using it would be to try and see what happens .. whether trackmarks end up in identical spots or not, basically. I doubt most equipment would even specify in their manuals whether they support this or not, too. I'm willing to bet though, that at least Sony's home equipment have this features.

Actually, there are [to my knowledge] two methods of sync-recording via optical-in. The first uses subcode offered by some CD players and included in the data sent via SP/DIF to the recorder. This method can actually copy tracks exactly as they are layed out on the CD being played. Many players do not offer this feature. The second follows levels and creates tracks the same way as recording via the analogue line-in. Either way, this player should work assuming it indeed has an optical-out.

See here: http://forums.minidisc.org/index.php?showtopic=7070 Basically, there is no way to losslessly transfer from MD / MDLP discs. All methods [excepting those used with specialised and very expensive MD computer drives] that exist involve decoding the atrac/3 data to PCM at some point, whether you're using the analogue route [which also means D/A and A/D conversion] or the digital-optical route with a deck [which doesn't involve D/A or A/D conversion]. The simplest method with a mac is simply to plug the recorder's line-out or headphone-out in to your computer's line-in as per the thread linked above. Despite involving decoding to PCM and subsequent D/A and A/D conversion, the quality of this method exceeds the needs of the vast majority of users, and even broadcasters [such as the CBC] use this method on a regular basis.

You can also create a playlist in SS, and sort it as you wish by clicking the column headers in the playlist before downloading to your player. This is in effect the same as making the playlist with other software [such as Winamp].

SS imports mp3s rather quickly for me. The majority of the processing involved in the task is simply reading the tags and indexing them in the SS database. It takes a couple of minutes on my machine [Athlon XP 2500+ / 512MB] to import/index a couple of thousand mp3s. The files are simply indexed by SS and added to its database. Depending on various options, SS can rename the files if you alter their tags at all, but other than this they should remain in their original locations, and not be duplicated in any way unless you tell SS to transcode them to some flavour of atrac/3/plus for downloading to any of Sony's players. SS has split and combine functions only for use with files recorded on HiMD and uploaded to your computer. Otherwise it has no facilities for editing existing files in any way, shape, or form. One reason for this is that SS is not intended to be an MP3 or WMA handler or editor. It is intended primarily for dealing with atrac/3/plus files. While some of Sony's players do accept the transfer of mp3s as-is, SS is limited to doing just that with them. The baseline here is basically that if you want editor features, use editing software. SS is primarily for cataloguing and transferring files, and its limited editing capabilities are for use with tracks uploaded from HiMD only. Lastly: folders vs. directories is simply a semantic thing. They are in reality exactly the same.

The first computer I ever used was a Commodore PET, in grade school. I then moved on to fiddling about was an Apple IIE that a friend had [with mouse]. I also used numerous Commodore machines, including the VIC-20, C64, and C128. Later I was a teacher's assistant for university extension courses in programming on Amigas [when I was in grade 9] in AmigaBASIC. At home I started with a coleco Adam with its version of BASIC and CP/M. The beginnings of my experiences with Z80 assembler were under CP/M with dual tape drives. The Adam, with a 300-baud modem, was also the first computer I used extensively for BBSing in the mid-1980s. The point at whiych I really got into servicing computers was with DOS 3.3 when I was in jr. high. I can still do memory optimisation for most of the various versions of DOS, including DR-DOS which I used for several years. I'll note that many consider DOS itself [in any of its variants] to not be an actual OS, merely an interrupt handler. The first "real" OS I actually operated under was VMS on DEC VAX minicomputers, again for programming in C, C++, Pascal, and for testing database software. I had limited experience with variants of *nix after that, mostly with HP-UX. This is also part of how I've been using the internet [one way or another] since about 1988. During most of high school I did most of my computer-related work at home with a VT220 terminal hooked up with a 2400 baud modem to a VAX computer across town. Late in high school when I was programming mostly in C / C++ and Pascal, I moved to OS/2. OS/2 is still my favourite OS to this day in terms of overall usability and stability [especially when programming], though I haven't used it in years. For a long time I was rather peeved with microsoft for having stolen the best parts of OS/2 for Win95. Later I discovered that other OSs, most notably NeXTstep and variants of BSD had many of the same features several years before OS/2. I've used Windows since v2, but didn't really get into things with it until 3.0 came out. My Mac experience has always been limited as Apple computers have always been significantly more expensive to purchase here. The primary reasons I got into PCs when I was in high school were that my father was partner in a computer store at the time [how I was exposed to Windows 2.x, which was truly terrible] and that I was enrolled in vocational electronics courses at school, where we used PCs in several roles, including simple robotics and machine control programming. In broadcast college we used PCs minimally in production. I was actually the only person in the year I was there to produce anything using edit control lists with a PC controller for the VTRs at the school. I'd been using Sound Forge since v2 and made some radio segments with it, which were also probably the only projects handed in that year that were made using a computer. We also used Amiga 4000s with video toasters to produce flying logos, and a donated [by TSN] purpose-built tablet-interfaced video capture and editing system for weather maps. My brief stint at an audio engineering college in Vancouver, BC, introduced me to MIDI software on Atari 520ST computers, basic audio editing on Mac LC-series computers, and the original ProTools/digidesign audio interface in the digital [sony 24-track DASH] studio. I held on to OS/2 for a long time after Win95 was introduced, but when Win98 came out and I could finally afford to upgrade hardware, I moved on. From there it was to Windows 2000, and from there to XP. In all honesty, even knowing my limited experience with them, I would rather be using a Mac. The cost difference [still 30-50% for comparably performing hardware around here] is too high for me to justify going that route at this point, though. I must confess, though, that I have read the history of the Mac [see www.folklore.org] and find the Apple story rather inspiring.