dex Otaku

No.

I post my opinions here fairly often. Opinions that have to do with MD and HiMD in particular, and Sony in relation to these formats. I usually come across sounding as though I honestly believe that Sony are the root of all evil, are only interested in making a buck, and don't care about their customers at all. I posted a rather rude comment in one thread wondering if some executive was/were bound to enact seppuku over the admission of omitting mp3 support being an error, among other things. Since then I've wondered about Sony employees coming to the forum and reading my opinions. I wasn't worried about someone from Sony thinking I'm an arsehole, to be frank. What concerned me was that what I said was dishonourable in the extreme. Please allow me to digress on this for a moment. Sony are not the root of all evil. I do not believe that their sole intentions are to screw customers, and despite what I say about their lack of service and support in regards to certain things, I do not think that Sony are a malicious company. Sony is a huge corporation. They are made up of thousands of people in countless different divisions. These different divisions work on such things as market research, product concepts, technical research and development, manufacturing, music and film production and distribution, software design, customer support, marketing/sales, product distribution... Further, they are divided into consumer and professional-oriented divisions. It's easy to see how wires may get crossed within a corporate entity this large. It's easy to see how different divisions might end up working utterly at cross-purposes with one another. It's also easy to see how a corporation that has worked in professional and consumer electronics for many ways might make some blunders crossing over into the territory of writing computer software. It's also easy to see how the directives of one division might cripple the innovations of another. I do not believe that Sony has designed SonicStage or HiMD with the malicious intent of making their customer's experience difficult if not actually unpleasand at times. They just happen to have made a few mistakes in the process, many of which were undoubtedly related to their different divisions giving each other orders that did indeed put everyone at cross-purposes. I can quite easily imagine the engineers who designed the initial prototype HiMD units throwing their hands up in despair over the crippling extent of the music and software divisions' demands regarding DRM. I can also imagine the SS software engineers sitting there saying, "You want us to do what?" Sony are not evil. Sony is just a company made up of people, and despite the tone I so often take, I'd really rather believe that those people have honourable intentions. I have both owned and used many Sony products over the years, from MD and HiMD equipment to U-Matic, Beta, VHS, Video8 and Hi8 video equipment to professional A/B roll video editing stations to televisions and monitors to computers to cassette and 1/4" tape machines to budget sound mixers to cameras to CD players to .. yeah. The list goes on. I'm not going to quit using Sony products because they've made mistakes. They've also done a lot of things right over the years.

Ah! I digress! There is another thread in the tech support forum which I copied this one from. The link is in that thread. [Reasons for copying the thread: #1 - I can't move threads; #2 - I though mMore people would read it in here than in the tech support forum, which would solve the problem more quickly] See here: http://forums.minidisc.org/index.php?showtopic=7832

DRM prevents this; this is the entire point of DRM. Unless you copied the tracks to a HiMD disc simply as data [using it as a removable drive], there is no way to get them back off the disc without copying them the old fashioned analogue way.

The word "done" in that post is a link to the package. I agree that we should start setting up torrents for these, though. There are more than enough requests to warrant it.

This depends on the complexity of what you're recording - some things compress more easily [with fewer artifacts] than others. For most music I would choose to go with PCM if at all possible. Yes, it would often mean changing discs. I usually record in HiSP. For picking up everyday sounds, snippets of conversation [with permission of course], interviews, &c. HiSP is great. I have used HiSP for recording sitar to no ill effect [though it was in mono]. I suppose it depends on how important the recording is to you; PCM is there so you can have an unadulterated first generation. HiSP comes in handy when you know that changing discs is an impossibility [because, say, the recorder is hidden in your jacket or something] or when you simply don't have all the blank media you need with you. I have yet to use HiLP for anything other than testing purposes.

ATRAC tends to fall towards the bottom of most independent ABX testing, from what I've seen. Mind you - the tests I've seen used material encoded by SS, which has been shown to encode not nearly as well as the hardware codecs in MD or HiMD recorders. Especially with LP2. I was totally put off LP2 because of SonicStage. A friend sent me copies of LP2 recordings she made with an MD recorder; the results were vastly superiour to any of the encoding I've heard SS do. Still, under most circumstance LP2 isn't enough for my tastes. I'd consider it well-suited for car listening, but I find it unbearable with 'phones. It also does quite well with mono recordings [thanks to joint stereo encoding].

There is a freeware program used for ABX testing already. Poke around on hydrogenaudio, members there use it quite frequently for comparing codecs and such.

Are you so sure about this? Lame encoded mp3s should in fact differ very little from HiSP. I'm interested in what you're saying about oscilliscopes. Considering the fact that it should be impossible to see nearly -any- form of audible artifacting on an oscilliscope [that doesn't do series-sample and hold]. Also considering the fact that one would usually use various forms of spectrography to spot artifacting, not something that displays an instantaneous measurement of a waveform. HiSP [in its first incarnation] has already been clearly demonstrated [through measurement] to not be as effective in encoding as ATRAC SP. It has also been shown to have the same ringing/pre-echo problems that the other forms of ATRAC do, to which regard are measurably outperformed by both the Lame and Fraunhofer mp3 encoders, due to mp3's slightly better abilities at handling high transients by switching between long and short blocks - something that [to my understanding, at least] ATRAC is bad at mostly due to the longer block lengths it uses. And yes, I'm skipping a bunch of the background information that explains what long and short blocks are for, and how transform windows overlap which is part of what causes many artifacts, and on and on. I might also be using a bit of ambiguous terminology in talking about block lengths, but then, it's 5am. An oscilliscope is a simple device that displays a measurement of voltage over a set time period [amplitude vs. frequency]. Most forms of artifacting are harmonic, and as such, would bring little in the form of "jaggies" to any signal [ringing and pre-echo would in a certain sense, but the display of these on an oscilliscope would pass so quickly that there's no way you could hope to see any but the absolute worst examples]. Fourier analysis is used to convert sampled amplitude data from the domain of time into that frequency. This and related transforms [usually discrete or modified discrete cosine transforms] are employed in the kind of analysis used to convert PCM data into the various lossy compression formats. Fourier analysis is not used at any point in PCM recording or playback, to my knowledge. The simplest A/D conversion is done using a resistor ladder network to convert variance in voltage to discrete steps which are measured at a given clock rate - the first giving bit depth, the second being the sampling rate. Others methods use variations of pulse width modulation [1-bit systems with extremely high sampling rates] which are then often converted to PCM for more common use. SACD's newer bitstream digital format is an example of one of these variations on PWM which forgoes the conversion to PCM. PCM A/D converters also do not do any form of math; they are not signal processors. They simply measure an incoming signal and record the measured value once for every pulse of their clock. Studios generally don't use any format that is lossy until the final step of the process - packaging the product for the consumer. MP3s have nothing to do with A/D converters. A/D converters do not encode or decode lossy formats; they convert analogue signals into digital, most commonly using forms of PCM and PWM. Furthermore, once compressed data is converted from the frequency domain back to that of time [i.e. to PCM], that signal is then converted to analogue by a D/A converter. I'm seriously wondering where you got the idea that mp3s cause A/D converters trouble of some kind, since they not connected in any way whatsoever. Unless, of course, you've converted that mp3 to PCM, then to analogue using a D/A converter, then put the resulting analogue signal back into an A/D converter. At which point the A/D could care less whether the source was originally in mp3; it's simply converting analogue to digital to the best of its ability. I'll agree with you here. Listening depends on perception; perception is subjective. What matters most is whether -you- like what -you- are hearing. I'm not trying to start a flamewar either; I'm simply pointing out that that your facts are more than merely suspect, but, for the most part, entirely wrong. I make mistakes, too. And I occasionally profess things that are entirely wrong because I simply haven't learned enough yet. I won't hesitate to correct misinformation, though, because other people are learning from this, too. If they walk away with a head full of wrong ideas, that's a bad thing in my opinion. I also welcome anyone to correct me if I'm wrong on anything. I would rather learn what's correct and be slightly humiliated for a few minutes than be wrong and not know about it.

Were you not aware of HiMD's upload ability and the existence of HiMDRenderer and Sony's Wave Converter? [Asking seriously, not patronisingly]

The question you're asking is much like, "What gear do I put my car in to make the window roll down?" Unfortunately, I concur with both skmetal07 and the Sony rep you spoke to - it sounds as though the disc is simply stuck in the unit. I would try gently sliding it out, perhaps by very carefully hooking the edge of it with something to pull it out. In any case, if the eject spring has popped out or off, you'll be looking at servicing it.

Depending on the situation where it's being used, it may be more convenient to use the on-board controls or the remote. When I use my player connected to an amp, I don't use the remote. I often use the display then. When I use the player as a portable with 'phones, I almost never look at the display [which is why the displayless remote that comes with the NH700 is fine for me]. Which is appropriate simply depends on how you're using it.

The simplest method for doing this as actually as follows: 1) back up your original recording in real time if you're paranoid like me 2) upload the recording using an installation of SS 2.3 to any of the computers 3) use HiMD renderer or Sony's wave converter on those tracks 4) delete or simply forget about the tracks on the originating SS machine Of course, you can then also: * edit or copy the tracks as many times as you like, free of DRM, without ever having to worry about using a second recorder or optical cables * back up the recordings to whatever other media you like without worrying about not being able to use the backups * convert the WAV files to whatever format you choose, including lossless formats more suitable for archival, which are still accesible and playable by any computer on the network * re-import them to SS on any machine and write them to netMD or HiMD * Play them back using any software you like, copying them in realtime via optical link to SP-format discs for use in your car [note that depending on what you use, track marks may or may not work properly] Keep in mind that all of this is assuming [if you're using Wave Converter] that the recordings you wish to copy are your own, and made using the analogue-in on one of your HiMD recorders.

Thank you for pointing this out. I took it for granted that at least SS v2.1 would be required, but I tend to forget that many others are still using OpenMG Jukebox or SS 1.5 and the like. The moral of the story is, simply: update your software.

MD as a format does not support high-speed upload in any form. You can copy digitally in realtime from home and pro decks that have an optical output. HiMD supports uploading via USB, within the limits of Sony's software and DRM standards. Wander around in the HiMD forum and you'll find many of these questions answered there.

I like the using my remote because it lets me shove the player in my pocket and basically forget about it. I have a tendency to wire the remote and 'phones cable through my clothing to basically make the player a part of what I'm wearing, rather than some thing that I'm carrying around.

The only way I've seen to contact their tech support is through the support forms on their website. They aren't likely to give you direct addresses to their tech support as they know that anyone they gave those to would likely spread the address, which would increase traffic from sources other than what their support departments are made to cope with.

The chokes are for filtering out radio frequency interference caused by the HiMD recorder. They are not actually for filtering interference picked up by the mic or its cable. If you want to have filtered power coming into your recorder, you have to replace the power supply with one that is regulated and filtered, neither of which the adapters that Sony include with their units are.

To add one thing to A440's reply: Digital distortion is caused by overloading the A/D convertor. This is clearly not digital distortion, as I have seen a chunk of the PCM which Wendy sent me; the distortion is happening before the A/D conversion takes place. This puts the blame on either the mic being overloaded because it can't handle SPL that high, or the mic preamp being overloaded by to high an input signal. In either case, moving the mic farther from the source will fix the problem.

I have made full disc-length recordings to HiMD using a single alkaline AA battery on my NH700. The most important thing to remember is basically to start with a fresh battery. Using good batteries is also a good idea. It goes without saying that the battery you're using has to have enough life in it to run that long from the start.

Lots of stuff on this topic.. but first, to dispel some myths: 1) atrac uses less power than mp3: This is only an illusion. The amount of signal processing used to play back either signal will depend mostly on the bitrate, and will be pretty much equal between the two. The place where you really save power is during playback of lower bitrates. A lower bitrate recording doesn't need to be accessed as fast or as often in order to be buffered for decoding - a simple example is that a single disc access at a fixed speed will read more of a 48kbps track than of a 256kbps track. This means you can read a whole bunch of 48kbps audio into the decoding buffer, shut off the disc, and then do everything from the buffer. With the disc not running, less power is consumed, so battery life is longer. atrac/3/plus would seem to contradict this in one sense: there are more sub-bands and a higher resolution transform is used, so it would make sense that it takes more processing to decode it back to PCM than a lower-resolution format [like atrac or atrac3, or mp3] would take. More processing means more power consumption. If the DSP is optimised specifically for atrac/3/plus it could counteract this, though. Comparing atrac/3/plus with mp3, though - I would expect that mp3 decodnig would be less processing-intensive to decode, meaning that even with format-specific decoder optimisations, atrac/3/plus might use the same amount of processing power as mp3 in the end. 2) ATRAC is more flexible because it can be altered while remaining backward-compatible. This is also an illusion. As with literally -any- codec, the decoder is basically a standard set in stone at it s most basic level. The encoder, on the other hand, can be tuned over time to improve performance while maintaining a stream that the decoder doesn't know any different from one made by an older encoder. Mp3 is probably the best example of this, actually. Because of the widespread adoption of the format, it has been taken and tuned to the point where it can far exceed its original specs. Lame and the like have done an excellent job of this, parallelling in many ways some of the many improvements made over the years to ATRAC SP as well as MDLP. Enough for the myths, though. Measurable differences between formats [such at all of the atrac formats' kown-distinct problems with pre-echo] do exist, and these are a concrete, objective thing. These can determine what formats are technically more accurate, though it is important to note that accuracy is not always what definitively says what is better to our ears. As far as atrac/3/plus [all of the variations, and in fact, the same applies to all codecs] are concerned, "better sound" is mostly a matter of personal opinion, based on perception and personal preference. This is subjective, and as such, does not actually determine whether atrac/3/plus are better formats than anything else. What it amounts to is that you can tune the encoder of any format as long as the stream it spits out is something that the decoder can recognise as valid. You can improve the encoder as much as you like, within the limits of what the decoder expects, and even older decoders will be able to play back the newer-version streams with improved fidelity. One more thing - with the disclaimer that I am not an expert an audio encoding, so some of this might be incorrect even if it makes sense to me in terms of all the studying I've done on the subject. The gapless nature of MD and HiMD are simply a matter of design intent. MD was made so that packets of audio matched those of CD, if I'm not mistaken - using a fixed length of samples encoded at a constant bitrate [CBR] for every block. Without doing this, both on-disc editing and gapless playback after editing would not have been possible. It's important to note that gapless playback between tracks recorded in one go and gapless playback between tracks that have been edited are two different things. Gapless playback in general requires that every decoded block end with a valid sample rather than padding data [as often happens with mp3 files]. Gapless playback on an editable format requires that every block have exactly the same length of samples. This may seem meaningless to many of you, but it's crucial to MD's editing capabilities. It's also a big part of the problem with atrac's pre-echo problems, since eliminating pre-echo requires encoding high transients with a different block length to make sure that the overlap between decoded blocks isn't so long that the echo is long enough to be obvious. This is why a ripped CD will be gapless, while transcoded mp3s can not be. Other than the original ATRAC codecs as implemented on MD, I don't know of any other audio codec than was designed specifically for gapless playback; the combination of variable block-lengths and variable bitrate encoding get in the way, for instance. There is no actual reason why mp3 and other formats can't be gapless; all that's required is that everyone follow exactly the same standard, and for block lengths [transform window-lengths, really] always be constant. The part about gapless playback that always gets me is that -all- players have to buffer the encoded data before decoding them for playback. All that's really required for gapless playback is that that playback buffer [not decoding buffer] be monitored for zero samples [padding], for those zeros to be tossed out, and for the playback buffering to seemlessly go from one track to the next. This is really simple to do [though it is processing intensive in a sense], and there's no reason why it shouldn't have been an option on every mp3 player in existence right from the beginning of their manufacture. Maybe I'm oversimplifying, though. It's mostly a matter of engineering or design philosophy. Most mp3 players work this way: * start buffering the encoded stream * decode the stream [play it back] * when the end of the stream is reached, stop [i.e. turn off the decoder] * start over again whereas what I'm talking about requires this instead [which in theory works regardless of variable block or window lengths or VBR encoding]: * ask the stream how long it is * start buffering the stream * decode/play back the stream * when the stream reaches x blocks from its end, start monitoring the decoded data for padding [zeros] * at the same time, start buffering the next stream [basically start from the beginning of this list again] * remove zero samples from the end of the first stream and the beginning of the next stream This may not make sense because it doesn't seem to have an end, but that's really the point - gapless playback never stops or turns off the decoder. It's constantly decoding, and runs in a sort of endless loop, rather than as a process that starts and ends discretely for every track. This is complicated by many things, though. First and foremost is that metadata, specifically id3 tags in mp3s, are not always the same length, because there are no fixed standards for this. This means that the decoder has to be able to recognise what is actually audio data or not, which may seem pretty simple, but a lot of players simple don't bother to do this - hence the little glitches at the beginning and end of literally every track played back on most cheap players. Add to this the fact that id3 v2 tags are placed at the beginning of every tracc, whereas v1 tags are at its end. Tags at the end can more easily be whatever length, because when the decoder reaches the beginning of the tag it simply ignores the rest. Tags placed at the beginning, however, have to be monitored until they end and the audio stream is reached. This is one of the reasons why there is actually an anti-id3 v2.x movement that has been around for a long time. And. Yeah. There's my $0.02.

Keep in mind the condensor microphones [most that require a power source, whether a battery or "plug-in power"] experience something referred to as "proximity effect." In plain Engilsh, the closer a condensor gets to the source you're recording, the louder the bass will get. Close-mic'ing a source will make the bass seem a lot louder than distant-mic'ing.

[Monty Burns style] exxxxxxcellent. edit: The file unzipped, installed correctly, and now I have PCM support in SB.

This isn't what's usually prescribed here, but user ereb has asked for help that has a time limit along with it: Anyone who has a "packaged" version of SS v2.3 they could download, would you please PM ereb with a link. Thanks all, D.

I'm assuming you were recording in LP4 mode. Do you have the recorder -IN- LP4 mode? SP mode records 80 minutes on an MD80, so it would make sense that if it weren't in the correct mode, it would stop there.