dex Otaku

Interesting bit here: [no pun intended] RandomHajile2 pointed this article on minidisc.org out to me while we were discussing something else: http://www.minidisc.org/mj_ja3es.html Assuming that HiMD's processing is a descendant of the ATRAC3.5 chips [a fairly reliable assumption] .. scroll way down, right near the bottom, and you'll get the news - YES, MD -always- resamples the digital input. Or, more accurately, it reclocks it to help eliminate jitter. Which means that it's next to impossible for anything to be recorded with excat bit-accuracy from a digital source, because the resampling will always impose some [probably extremely minor] shifts in timing, and probably be interpolating samples when jitter actually does occur. Or at least, that's what I got out of it. Still - I'm making the assumption that what applied to the 20-bit I/O pro deck in 1995 has made it into the portables of 2004. Which still seems a fair bet, to me.

No, they're not wrong. And neither are you - but read what you've said. The audio is quantised as 44.1kHz 20-bit PCM, then encoded to ATRAC [at which point it has no bit depth in the traditional sense], which is then decoded back to 44.1kHz 20-bit PCM. What goes in is PCM. What comes out is PCM. These have bit-depths. The ATRAC audio that is stored does not, per se. And, as I said, you can decode the compressed audio to whatever bit-depth you want, but you cannot exceed the resolution of either what came in or what the limitations of the CODEC impose. Furthermore, if you actually -read- the document you linked to, they explain in excruciating detail all of the reasons for what I've been saying all along. I think the whole issue here is that you and I are actually agreeing with each other, with the exception of one really minor detail. [The agreement being that higher resolution in = higher encoding accuracy, logically follow by higher resolution decoding = higher decoding accuracy; the disagreement being over only one thing, really: the compressed format itself does not have a bit depth in the traditional (i.e. PCM) sense, though you would argue that whatever the bit depth of the signal being encoded is, is the bit depth of what's being recorded, which is incorrect.] It's been sort-of fun but maybe we can lay this to rest. Agree to disagree, or something. Because I'm sure there are more useful conversations we could be having than to keep rehashing one single point over and over ad nauseum. I hated U-Matic when I was in college. The year I started they'd replaced all the 3/4" equipment with Hi8 camera backs and VTRs. Some things we still had to use 3/4" for though, and I always found it a pain in the arse [mainly because the equipment was old and fairly unreliable]. My father and his friends/colleagues started the local cable co-operative here in the mid-1970s. He'd occasionally bring home one of the studio U-Matic VTRs so we could watch a movie they'd taped off one or another satellite feed. I suppose it's no wonder I've ended up doing the stuff I do/have done.

Marc: A few minor "feature requests"... For batch mode: 1) in the search path box at the bottom left - it would be cool to be able to go directly to -only- the SS libary's HI-MD folder, rather than the whole library. 2) Somewhere to specify a destination folder would be a definite plus [though not absolutely essential]. Also: I hadn't mentioned it before, but batch mode has done this consistently on my machine since you put it in.. If I try to render more than 30 tracks at a time, it will start reporting that it can't decode the 31st [click okay] the 32nd [click okay] until after a random number of aborted attempts HiMDRenderer simply crashes. It appears that the OMA renderer itself actually stops. Doing files in batches of 30 works fine. Lastly: have you looked at the way options are laid out for FLAC in some programs? I look at the options you've listed and assume that things will be okay with the default, because they don't resemble what I've seen from foobar2000, FLAC Frontend, or basically anything else I've seen that uses FLAC. Sorry if these seem like harsh criticisms. They're not meant to be. Your efforts are sincerely appreciated by many here. edit: Hmmmmmm... FLAC has provisions for metadata. mp3 has id3 v1 and v2. OGG Vorbis has provisions for metadata. and.. SonicStage has a database of track names, numbers, &c. [i have no idea whether the OMA files as kept in its library still hold the info internally]. This is a long shot as I see it, but shouldn't it be possible to pass SS's metadata on tracks directly to whatever format [excluding WAV since it causes more problems than it solves, usually] a file is being exported to? This way if people are titling their own recorded tracks, that info would get embedded into the files they export to, making them a heck of a lot easier to manage than filename alone allows. Side-point: the lame and FLAC codecs, and I'm sure Vorbis as well, have parameters for passing tag info to them at time-of-encode. Do they not? It's a thought. I sincerely wish I were still a programmer. edit 2: Correction - After doing 30 files, I have to close and restart the renderer as it will not decode anything past that. edit 3: After checking your message board I see that you're already aware of this. Heeee.

It probably has a lot to do with several "silly" factors: 1) A lot of people can't figure out how to download something like Firefox and install it. Or at least - not how to do so properly. 2) Installing software on a business or government computer usually requires a sysadmin to come login and do so for you, or for them to install it on the server and update everyone's desktop to include the icon. For them to do this, they often need not just permission, but "orders" to do so. 3) A lot of places have things set up so people can't install software [requiring admin accounts] but no one in their actuall offices even knows how to log in as an admin, or they lack the credentials, and they have no local sysadmin. These are the usual cases here. Which is funny, because it makes government offices [municipal, provincial, and federal alike] and high-profile businesses among the least-secure networks in existence.

There's also the fact that properly used EQ should NEVER go into gain; it should always -only- be subtractive.

Not to be totally glib, but the straight truth: 1. If you have even remotely discerning ears, 48kbps HiLP is garbage. I would consider using it for recording [on the unit, not through SonicStage] mono voice recordings only. Music through it is completely unacceptable IMO. On the other hand, if you're happy with formats like mp3pro [i.e. formats that generally sound terrible] you might might be happy with 48kbps HiLP. 64kbps HiLP, while not to my taste, is surprisingly decent and a number of people here have expressed how happy they are with it. 2. HiLP vs. HiSP or SP: night and day. The average person would have no difficulty telling the difference between SP and HiLP at either 64 or 48kbps. Whether they would find it annoying enough to totally avoid using it [as I do] is another matter. So basically, yes - the quality would be horrible. Mind you, that's all subjective. The only real way for you to tell is to do your own comparitive listening test.

The key is to backup your own recordings before uploading them with SonicStage. You can do this by analogue means [as with any MD, or for that matter, any piece of audio equipment with an analogue output] or by digital [with software such as Total Recorder].

If atrac CDs work the same way that atrac does on MD and elsewhere - you will only be able to decode these on the computer that made the disc. As I have no experience with atrac CDs, I can't guarantee that I'm totally right on that. Were did you get the disc from? Did you make it yourself?

Well.. MD and HiMD are, I would assert, the only portable formats currently existing that are both recordable and removable, without being solid state [and thereby prohibitively expensive, for now at least]. That is with the exception of both CDR and DVD+/-R, neither of which are as small or as durable as MDs or HiMDs. Hard drive brands? Do you hard disc recorders? Most of the hdd-based players out there that also support recording are rather anemic when it comes to supporting features that one would expect on a recorder [like record level meters, record level controls, &c.]. If you're not that interested in using the unit to actually record on location, this won't be a big issue for you. I also would not consider anything hdd based as permanent storage - portable hard drives [as with all hard drives] have limited lifespans. We're talking about 3-4 years with ginger treatment vs. a probable 10-30 years for an MD [figures I'm making up but feel fairly comfortable have done so - if I'm totally out to lunch on that - anyone - please do correct me]. Backing up discs - the simple answer is no. Thanks to Sony's DRM, you can't transfer something back off a disc once you've put it there. There are workarounds, such as copying off the disc by analogue means, or copying it digitally in realtime using a program such as Total Recorder, but I doubt this is the solution you're looking for in this case. On the other hand: generally, you put things on HiMD by adding them to your SonicStage library on your computer first. When you put something on HiMD, it doesn't disappear from your library; you can put it on other discs. You can also backup your library to DVD+/-R or CDR, which, with 600 CDs, is likely to take both a large number of discs and a lot of time. Mind you - ripping, encoding, and transferring 600 CDs to HiMD would take a lot of time to begin with. NH1 vs. NH900: Most of the differences are superficial, but some of the key ones are: All-metal case [NH1] vs. half-metal case [NH900]; one-line vs. three-line display; the NH1 comes with a slightly nicer remote that includes record level meters on its display; and the NH1 is slightly smaller; the NH1 does date/time stamping on recordings you make with it; the NH1 uses and comes with a Li-ion battery, whereas the NH900 uses and comes with a NiMH battery. Take a look here: http://minidisc.org/part_Sony_MZ-NH1.html Note that at the top of that page you can jump to the NH900 specs, or by clicking 'all' you can see all of the HiMD models on the same page. Cheers.

The MZ-R500 is not a downloader [netMD]. You can record from your PC to the MD with a simple 3.5mm stereo [to same] cable going from the line out on the PC to the line in on the MD. Or did you typo the model number? I don't know what software would come with a non-downloader, either. You say that you had a CD that came with your R500 and lost it?

There are several threads in the HiMD forum regarding SS's trashing of tracks, with at least on in the HiMD info/FAQ subforum as well. Please take a look there. Also note at the top of the page where it says, "Search". Clicking it takes you to this page where you can do this amazing thing: type in a search string, such as "sonicstage trash" and have it find all the threads with those words in it. You might like to try it some time. Sarcasm aside, since there are several threads in the HiMD forum that mention SS's trashing of tracks, searching in that forum alone is a good way to find them - especially since most of them have slipped off the first page and will be a pain to find. I happen to know that almost every one of them uses the term "trash" though, which is fairly unique on here from what I've seen - making the search pretty specific, and what you're looking for easier to find.

You can plug it in whenever. Just hit the stop button until it says 'charging'. Cheers.

First off: this should be in the tech support forum, not the HiMD forum. Barring that - What was the track's source? Was it recorded from an analogue source on the unit, or via optical? In those cases, you can transfer the recording to SonicStage, yes - but if you try to do so more than once, it will delete the track on you. If the track was from any other source, including another computer, in fact even from your computer, and was transferred to HiMD via SonicStage - you guessed it. Not only does SS not allow you to upload these, but it will delete them if you try. On one hand, this is part of Sony's DRM. BTW - these things ARE in your manual. On the other hand, I'm fairly well convinced that a lot of the software engineers Sony hired for SS are outright sadists,

Did you turn the charger on? Pressing stop while the unit is plugged in but not running turns on the charger. Also, this should be in the tech support forum, not the HiMD forum.

We were talking about audio compression, not video compression. Hence the assumption. Sorry. Check here: http://www.dtsonline.com/media/uploads/pdf.../whitepaper.pdf DTS is in fact a different type of sub-band coder from those such as MP3. Still, it is a sub-band coder nonetheless. End result: when they say it's 20 or 24 bit, what they're referring to is the encoder's ability to handle that resolution of PCM input stream natively, without requantising it. The stored DTS stream itself, being compressed, does not have a bit depth in the traditional sense. I don't doubt that you do. That doesn't mean that every single thing you know is correct, or that there's nothing left to learn, though. The same applies for myself, of course. Because your resistance to understanding the fact that lossily compressed audio is not PCM, and therefore does not actually have a bit depth in the sense that PCM does, is frustrating the hell out of me. My apologies. I know it's not necessary, and is in fact a childish thing to do. If you preferred, however, you could take your reasoning over to HydrogenAudio, where posting it would immediately have 50-75 people jumping on you to tell you why you're wrong. No. No, no, no. If it's PCM, there's bit depth. Other stream formats like DSD and every lossily-compressed one that I'm aware of don't have a bit depth [or, if you prefer, with PWM the depth is 1 bit - but since it's a different modulation system, the question is moot, PWM does not have a bit depth, only a bandwidth]. And what does it get converted to? PCM, usually. The thing is - and this is one of the great advantages of lossy formats in general - you can take the compressed stream and decode to whatever bit depth you want, because the stream itself has only a bandwidth [data rate], not a bit depth. Yes it is. I meant in the sense of lossy compression [which, technically, is also incorporated into the SACD standard, see http://www.superaudio-cd.com/technology_ex.../whitepaper.pdf ] but in any case, yes - DSD is losslessly compressed from a PWM stream at 64 times the sampling rate of CD [with 1/16th the number of bits of course], or 2.8224 MHz [4 times the data bandwidth of CD audio for stereo, if I'm not mistaken]. So, let me rephrase the whole thing from the start, then: PCM has a bit depth. Lossy formats [and PWM] have a bit rate, or signal bandwidth. In the case of PWM, it could be argued that it has a bit depth of 1 bit, but this is really a misnomer in my opinion. A depth of 1 implies no depth, for one thing. For another, it is called pulse width modulation for a reason. In the case of [most] lossy formats, there is only a bit rate, independent of depth. The higher the depth of the PCM signal it was coded from, the higher the accuracy of the encoding. The higher the depth of the decoded PCM signal, the higher the accuracy of its decoding. However, it being lossy, the comparison is moot - regardless of what came in, what comes out will be lower in overall resolution. You could say that [most] lossily-compressed formats, though not by definition having a bit depth in the sense that PCM does, they do have a reference bit depth - that being the depth of the original stream they were encoded from. The actual compressed stream itself does not have a bit depth, though. Interesting point though: as has been proven with ATRAC's newest incarnations, the compressed format itself can actually exceed 16-bit PCM in terms of dynamic range - probably because it is free of bit depth constraints. Of course, the source would have to be that good for this to be true. Compressed data from a 16-bit source can be decoded with higher accuracy to, say, 20 or 24 bit PCM. However - you can't exceed the resolution of what went in. Ever. Period. You can't make something out of nothing. This is the equivalent of blowing up a 100*100 JPEG to 600*600 and saying it's a higher resolution picture. It's not higher in resolution - it's just bigger. In the case of, for example, DTS - which also does a lot of funky processing to load the available bandwidth better, this can mean that in certain senses it is in fact exceeding the quality of the input signal. The thing is, it's still lossy. I would compare DTS in some senses to dbx bandwidth compansion in analogue recording; you are in fact loading the tape better in terms of signal balance and dynamic range, but you are also introducing artifacts into the signal at the same time. So, again: PCM = bit depth. Lossy = bit rate, independent of depth. Last thing: I kept saying 'most' lossily-compressed formats, because there are some that do simple bit reduction or requantise audio to nonlinear PCM [most commonly 10 or 12 bit] that do in fact have bit depths, but then, they aren't sub-band encoders. Some sub-band encoders, such as DTS, does use these methods within them [ADPCM] though. edit: Incidentally - 44.1kHz was chosen because the predominantly available digital audio mastering recorders that existed when CD was brought about were Sony's PCM-1630s, based on their U-Matic 3/4" tape format, which was [originally] used for broadcast-quality video recording. See http://en.wikipedia.org/wiki/Compact_disc . I have actually used U-Matic equipment, and at least got to load a PCM-1630 once for backing up tracks from a Sony DASH recorder.

You're lucky that the track was still playable. Every time SS has trashed a track on me, it was destroyed [unplayable] on the disc.

HiMD also requires space for file tables, the DRM info, track and album titles, &c.

Windows itself [the interface, not the underlying parts] was based almost entirely on the work that M$ did with IBM on OS/2 v1.x [which was a 16-bit OS]. NT didn't come until much later, and was actually an attempt at porting an OS that M$ had started developing for RISC systems to the x86 architecture [which is why is had so many problems, and still does, since the different architectures require different OS design philosophies for the underlying layers]. OS/2 actually had many incorporated ideas that completely blew away every other desktop PC OS that existed at the time. Their major mistakes were in trying to push a full 32-bit with virtual memory &c. at a time when memory and permanent storage were still very expensive. As a result their market was severely limited [mostly to corporate use - up here in Canada almost all banking institutions, government offices, &c. ran exclusively on OS/2 and later with cheaper Windows 3.1 - with OS/2 servers] because the machines required to run the OS would be too expensive for the average person. IBM are also notoriously bad as marketing their products to consumers rather than corporations. The narrow market meant few developers made software for it. Win95's interface, with right-clicked context menus &c. was lifted almost directly from OS/2 2.x. Also interesting to note, though: most of the places where OS/2 were found were places that required guarnteed running stability, such as 911 call centers, hospitals, banks and other financial institutions, government offices [such as the Canadian tax departments], and most notably software development houses. Many custom-written *nix programs such as databases &c. were written under OS/2. A fair amount of Windows 3.x software as well, since you could crash Windows under OS/2 and then simply close the session and open a new one. So - sure, OS/2 was nothing to write home about. It was just stable, usable, and versatile, especially compared with MS's offerings.

Do you have AVLS turned on?

Look in the HiMD forum - there's a subforum of FAQs and info. One of the threads there gives instructions on how to do this.

No, there's nothing you can do. If the original installation of SS and the OpenMG drivers were lost, along with their DRM keys, the only way you can regain your library is to rerip / re-transcode all of the tracks from their original sources.

That's an interesting name you've got, there.

No actually, what I'm saying is that there's a stickied thread in the netMD forum about how to transfer MDs to PC.

Pretty much all professional broadcast and film equipment are made to sync using one form or another of SMPTE time code. The audio recordist on film/TV set usually controls syncronisation for all devices present using a master clock in their recorder or on the cart near their recorder. All slates and cameras are sync'd to it by plugging them in at the start of work on a certain location. For professional film/TV use, SMTPE is a requirement - something that it would be really great if pro versions of MD/HiMD could support, to be honest. As someone who has been a still photographer [using 35mm film almost exclusively] for a number of years, I both agree and disagree with you about film. HD formats do have certain advantages, including higher sensitivity than film, higher exposure latitude [contrast ratio], far lower cost in terms of materiel, &c. Film on the other hand has a more appealing look to it, and is capable of doing things that no CCD image sensor will ever be able to, such as extremely-long exposure photography without the massive constant signal processing that any [digital] video format would require. Film equipment is also highly embedded in the industry, meaning the equipment is far easier to find and is limited to a few very well-known standards that have been around for quite some time, for the most part. It has also evolved with its companion technologies; film is not rudimentary in any way. It is highly versatile. One of the best reasons I've seen for still using film though: The standard 'flat' [non-anamorphic] shooting format for films and television uses an unmasked frame, meaning the entire usable area of the frame is still exposed despite only the 16:9 ratio area in the [vertical] center being used for later editing. The advantage to this [despite it seeming wasteful, perhaps] is that while they are shooting a scene, the director, camera op, and sound recordist can see vertically above and below the shot - meaning they'll know if the boom or mic, or cables, or special FX equipment, &c. are about to move into the top or bottom of the frame by accident - and they can take action to correct it without having to reshoot. With HD the frame is 16:9, with no safety zone around it. Even standard TV equipment has overscan - but HD [so far] does not. Which means if the boom op sinks the mic a bit low, no one knows it's happening until the shot is already ruined and has to be redone. Anyway. Indeed. Its intended purpose is multitrack [and I had that wrong - it's 6 discrete tracks plus a stereo mix] recording for syncing with film or video. The whole thing, though.. its apparent durability, the look of its design.. it just looks like an industrial design work of art to me. And a highly functional one, at that. With 6 track audio you could go out and capture, in the wild, a quad mix [surround ambience] using dual M/S mics as well as a forward-looking stereo mix with another for use in a 2-channel mix later. Or a quad surround mix, verbal cue track, and a large-diaphragm condensor mic for the LFE channel. I like to fantasise about it, for some reason.

The one time this happened to me I used the "initialize" option [found by hitting 'properties' at the bottom right-hand corner of SS while in the Transfer window] and it fixed the problem. The other option would be what bhangraman suggested.