dex Otaku

I've seen debate on this since I first started with SS 2.1, and yes, SS's codecs have improved [look in the tech section for my recent thread on unscientific testing]. Software encoding does have the advantage of being easily upgradeable, however, the intent of software vs. hardware is obviously different for the vast majority of users. Hardware encoding, while being basically set in stone once the unit is manufactured, is intended specifically to do the best job possible to meet the expectations of those who are making first-generation recordings [or encodings, depending on how you look at it]. Software encoding is intended for quickly copying a track from your computer to a portable device, whether by 1st-gen encoding or transcoding from another format. There are numerous possibilities that affect the quality of software codecs' output, including choosing to optimise for speed rather than quality, and choosing to optimise the encoder for transcoding from another format - such as MP3 or WMA, which have artifacting profiles of their own which a transcoder could be made specifically to do the best posible job with, with as little further degradation as possible. It has been generally opined that Sony went for speed rather than quality.

As with all MDs and any PCDPs out there, the data is read off the disc into a buffer, then decoded to PCM, [unless it's PCM to begin with], then sent out to the digital to analogue converter. The data in the buffer is whatever is read off the disc - if it's a3+ or mp3, then it's compressed. If it's PCM, then it's not. I am not sure as to the specifics of the buffer size.

Chances are, unless you specifically set up your user account to not be an admin, it's an admin. I'm confused about what version you're actually running, so please - open SS. Go to the help menu, click "about sonicstage" and tell us what the version numbers are that it's listing. My SS 3.3 installation comes up with the following list, to give an idea of what you're looking for there [you can copy/paste from the about window] Are the icons on your desktop lingering from a previous version/install? They don't do anything? The prog doesn't complain about your account not being an admin, or give an error, or anything? Nothing happens? More information would be helpful for us to help you. Also, this thread clearly belongs in the Software Support area - try reading the posting guidelines in that forum, and come back to us. Thanks.

If you're using SS 3.2, there's no need for the WAV conversion tool. Go to your library, select a track uploaded from HiMD, right-click it, and select "Convert to WAV format" from the context menu.

Great link to the Sony history, A440. I love corporate propaganda writing.. Here's a great quote: Hmm. Other than, say.. vacuum tubes, is anyone out there aware of some other type of memory than semiconductor? Talk about blowhards.

Heh, I also hit the wrong thing under "computer" .. all I read were the words "computer" and "games" on the same line, so I answered "virtually none". Most days my real answer would be >8 hours.

I tend to use HiSP. This reflects the average bitrates of the MP3s I both download and distribute [of my own work]. In the future I'm likely to use a3+ 352kbps for making demo compilations or discs for shows [to be played on location]. Up to now I've used both PCM and HiSP for this purpose. I find that HiSP is of sufficientmy high quality to not annoy me when using HiMD for portable listening. It's possible that if a3+ 352 support was added to Simple Burner, I might use it more often, but until that happens [which seems unlikely as even SS 3.3 was an unexpected release] I'll continue using primarily HiSP.

As long as the connectors are the same, they should work. To carry the USB logo they must meet certain quality standards, though that doesn't mean that some cables aren't still better than others. I, personally, have used cables from cameras and other USB peripherals, and found that short cables at the least have little difference between them for use with HiMD - especially considering the fact that HiMD uses USB 1.1, and not even to peak rates [12Mbps] at that. It's pretty hard to go wrong. That said, using extension cables can cause problems with transmission errors from signal loss due to mismatched impedances, same as pretty much any kind of cabling with any kind of signal bandwidth.

Unfortunately, I can't find any registry keys relevant to uploading. There are several keys which are strings of flags run together, but I have no way to check what they do, if anything, related to the "delete after upload" option. Since I can find no way to change this in SS itself, I can't test the flags. I would suggest contacting Sony Customer Support to see if they can provide a way to change this. If they happen to give you a way to do this, please do share it here.

HiMD, being a hybrid magneto-optical medium, is not super-speedy. Read speeds for PCM tracks during uploads average [for me, and this has been consistent since v2.1, the first I used] at between 2.5 - 3x realtime [which I've found consistent both with my NH700 and RH10], which seems awfully slow, yes, but that's the reality of the medium and nothing more. HiSP and HiLP recorded tracks should be proportionally faster. I've seen this, inconsistently, with all versions since 2.1. Sometimes SS takes time to wake up, sometimes it sees the recorder immediately. I find that the best way to do things is to plug the unit in before starting SS or Simple Burner. Doing things that way, I've found that either one will immediately see the recorder upon startup. Also note that if you have background processes that use any degree of CPU time, SS will generally take longer to "see" the recorder. This is happening because you told SS to do it, either during installation or when you made your first upload. Unfortunately, I can't find any option in SS that allows you to turn this off once it's turned on - quite alarming, actually! The only thing I can suggest is that if you're running a version that's pre-3.3, that you upgrade and tell the installer [which hopefully should ask even if you've had this option turned on previously] not to not to delete files from the original disc after uploading. If you're already running 3.3, I have no suggestions. I'll check my registry to see if this option is easily found and can be altered that way, and will post again soon.

What was the originating format, including encoding type and sampling rate, of the tracks?

I said aesthetics, but then, when given the opportunity I chose by colour. Colour is part of aesthetics to me.

£7.99? Wow. And I thought we had it bad - that's almost $20CAD per disc.

Okay.. thanks for elaborating. Agreed, though again - the watermarking is pure speculation. As for 24- vs. 16 bits, to me it's not so much that high-res souns better, it's that it lasts longer through editing cycles with less degredation through successive passes of processing. Properly-exploited, 16-bit audio is fine to me; I'd take as much resolution as possible in the original conversion, though, just for the sake of reducing error as much as possible, at least until the final stage before distro. I tend to edit even 16-bit audio in 24-bit mode, with DSP as high as the res of each plugin allows, with a final pass of requantising and dither before it hits an audio CD. I encode most lossy distro sources from dithered 24-bit data. It may seem like overkill, but I've made it a habit, and there are times when the difference is noticeable. Yeah, we're wandering off-topic, but thanks for the interesting sub-discussion nonetheless. Cheers.

Um. Wha? Can you elaborate on this a little, please? Digital sampling is not a form of data-reduction. It is sampling. Past a possible low-pass filter used to elimnate distortion by frequencies above the Nyquist freq. of a given sampling rate, whatever signal comes in to an analogue to digital converter should be recorded [i.e. sampled] to the best of the ability of that ADC. No data gets "thrown away" in the process, though some is purposely filtered out, and the process itself always has limitations that cause [mostly] well-known types of distortion. Data reduction, i.e. lossy compression, is another matter entirely, but we're talking about straight, uncompressed, lossless PCM recording here, not recording with lossy compression. The resampling issue and its side-effects aside [which should exhibit about as much change in the recorded signal as adding dither does], what goes in should also come out. I'm interested to know where you came by this viewpoint, or if I'm mistaking the context you've said the above in. Cheers.

1 - As stated by Sony's engineering division [it's in one of the docs in the research section on minidisc.org, unfortunately I can't recall which as I read it probably a year ago], all MD and HiMD recorders resample their input [not just reclocking, but resampling], even from the optical input, even when the sampling rate is already 44.1kHz. This makes absolute sample-accurate copies completely impossible, but doesn't necessarily mean a trashing of the quality of what's coming in. Any allusions to "fault" are themselves faulty, since this is done on purpose. 2 - The microtrack can record in 24/96 - I assume if you're trying to make sample-accurate dupes directly from it, you're recording on it in 16/44.1, but you might want to check this to make sure [the HiMD itself shold not be able to recognise anything at a rate higher than 48kHz in any case, so it's doubtful that this is the problem]. If you really want to check the by-word accuracy of the microtrack, plug it into something that you know does no reclocking or resampling, and check to see exactly what it's putting out [i.e. 16/44.1 if that's what you've set]. If you're recording in higher than 16-bit res on the microtrack, the HiMD recorder is likely truncating the incoming words to 16-bit if it recognises longer wordlengths at all. 3 - A difference of +/-50 [out of 65,535 plus sign bit] is awfully small, if that's what you were measuring by at least. 4 - While I'm pretty sure that manual levels does work over the digital-in on HiMD [i have never had the oppotunity to try it, myself], if you really want accuracy, don't use it. Having it disabled [the default] should copy exactly what's coming in, level-wise, keeping in mind that everything is resampled. 5 - Totally a side-note - I have run both my NH700 and RH10 to make a 4-track recording [from analogue sources] to be manually sync'd later, and noted that their clocks did appear to wander relative to one another, even taking into account the fact that Sony's implementation of auto-trackmarking while using line-in [which can not be disabled] causes tiny repeated sections of inconsistent length where track marks occur. The end result was that my two [PCM] recordings had to be manually resync'd multiple times over the duration of the whole recording to reflect the drift. 6 - the microtrack might also be watermarking its output, though it's highly doubtful; there has been speculation that HiMD recorders might be watermarking their input as well, which, given Sony's track record, is slightly less doubtful. Cheers.

I could only test bitrates supported by HiMD.

Thanksi but I am not allowed to use the messenger feature of this board. email me, Ishi.

I have measured the output of my RH10 at full volume to be just slightly below 1V peak to peak with a full-volume recording [test tone at 0dBfs]. This should be comparable to most home stereo equipment, in particular older equipment whose output is slightly less than more recent sources like HiFi VCRs, CD players, and the like. Note that when playing MP3s on 2nd-gen HiMD units, the frequency response is sloped off 9dB above 1kHz. This is part of why it's so much quieter playing MP3s - the bulk of the signal is being reduced to less than half its original amplitude [almost exactly half its perceived volume]. See here: http://forums.minidisc.org/index.php?showtopic=10621&hl=RH10 Oops, sorry the the hilight in that link. The original images [graphs] are missing from that post. I'll see if any of the mods will re-insert them for us.

If any mod is willing to take the task, I have the original images from this post still and they might be useful to re-insert.

The jack should be compatible with mono microphones with no troubles. Are you using the unit to record from a mic source with the AC adapter plugged in? This can cause different interfence problems including hum and crackling, and varying noise when you touch metal parts of the unit [like screws exposed on the outside]. If you're getting this while using battery power, then perhaps either the jack or the plug on the mic cable is dirty. An easy way to test if this is the issue is to turn the plug gently in the jack with the unit in record-pause and your headphones plugged in to monitor; if it's really dirty, you'll get the sound cutting in and out and lots of crackling. Cleaning the jack inside the unit can be difficult and it's relatively easy to damage it if you try. If it's dirty or if the jack is suspect, I would suggest having the unit serviced by Sony, hopefully under warranty coverage. A local shop could also likely help with cleaning the jack alone for a minimum bench fee or even less, since it would take less than a minute to do.

Note about the phono thing: you'll need a phono preamp to do this, or a turntable with a built-in preamp [most of the cheap 'tables I've seen recently have built-ins].

An addition: AAL is basically useless unless you use SS for regular listening - better than AAL support would be enabling support for all installed directshow audio codecs so that any track in a format the user has installed a codec for [including FLAC, WavPack, APE, shorten, and other formats widely used by recordists for lossless archival] can both be played and transcoded to a3+ formats within SS. Arguments against that would seem to be that it would widen the door to copying pirated music to your portable, however - anyone with greater-than-newbie computer experience can figure out how to convert whatever they want to WAV and import it into SS for transcoding. Also, the fact that MP3 support is built-in, as well as unprotected WMA support, completely negates any possible logic in this thinking. The fact that what is purported to be the most widely-used encoding format for piracy is already supported, MP3, takes care of this quite neatly. MP3 support in SS already uses installed directshow codecs. I use ffdshow's mp3lib support with 24-bit decoding and noiseshaped dither with no problems whatsoever and have done so for about a year - it even lets me apply decent EQ to SS's mp3 playback if I so wish. The only real issue is that metadata support would present issues for the SS programmers. This is also a near-null argument; most other audio formats use only a few variants of tagging schemes [the most prominent being id3v2.x and APEv2] as can be exemplified by the excellent tag-retrieval and editing support in other programs like Foobar2000. Sony deliberately exclude support for other file formats, despite their legitimate use in recordist circles, lossless-packing formats in particular. Sites like archive.org carry hundreds of 100% legal downloads of recordings - many of which were originally made with MD or HiMD recorders - in formats like shorten, WavPack, and FLAC. It's pretty ridiculous that they should exclude support for them when it could be as simple as allowing the program to recognise their file extensions and enabling support for directshow filters that are either purchased, free, or open-source - the enabling of which will infringe on no IP laws whatsoever.

Do you mean downloaded, or uploaded? It sounds like you mean uploaded. I already wrote a yet-to-be-revised howto detailing my methods. [minus specifics about editors et al, that is]

Doing some listening tests tonight to see how the atrac3/plus codecs in SS 3.3 fare. Note that my comparison with older versions of the codecs is from memory, and thus highly fallible. This is note an AB/X test or anything even mildly scientific in nature. It is simply me switching between tracks that I know the properties of, and comparing them by ear. Take these results with a large grain of salt. I used only one test track: "Railwayed" from the 1990 album Strange Free World by Kitchens of Distinction [band from Wales]. I chose this track because I've been using it for test purposes since the early 1990s when I got the album [original CD]; it is sonically very dense [high activity across the spectrum all at once] and has a heavy [but not excessively bright] high-end that very easily pushes equipment like A/D and D/A converters, makes plainly audible distortion in players that have bad synchronisation, clocking, low-pass filtering, or are experiencing high read error rates or jitter. It's absolute hell for lossy codecs to encode; encoders of any bitrate are pushed right to their limits in trying to do a decent job with the full audio bandwidth, let alone the densely-packed high-end of this track. I have used this same track to run bitrate comparisons in SS before, but not since v2.3. Encoding was done on my Athlon 2500+ (barton) with Windows XP SP2, and 512MB of RAM. Tracks compared using my RH10 and Sennheiser HD330s, EQ disabled: * PCM reference track, copied from CD by SS * 48kbps "normal", copied from CD by SS * 48kbps "high quality", copied from CD by SS * 64kbps "normal", copied from CD by SS * 64kbps "high quality", copied from CD by SS * 105kbps [no quality setting available] transcoded from PCM * 132kbps [no quality setting available] transcoded from PCM * 256kbps "normal", copied from CD by SS * 256kbps "high quality", copied from CD by SS * 352kbps [no quality setting available] transcoded from PCM * 48kbps-base "high quality" AAL transferred in normal mode * 352kbps transcoded from 48kbps-base "high quality" AAL Results, keeping in mind that this is totally unscientific and personal opinion based on my own perception: * The PCM track sounds as expected, and reveals no obvious errors in extraction from the CD. * 48kbps is substantially better than the last time I did this. There is obviously a great deal missing from the sound. * 64kbps is improved as well. The difference between 48 and 64 is noticeable in there being less missing from the high end. * I would still choose not to use either HiLP mode for portable listening [as they both give me the feeling that I'm listening to low-bandwidth internet radio], but either would likely be great for in-car listening where ambient noise levels are relatively high and playback fidelity is often compromised in many ways. * difference between 48kbps and 64kbps HiLP in "normal" and "high quality" modes is not obvious in any way. * 105kbps sounds substantially better than it did before, but that's not really saying much to me. I would still choose not to use it, as it still feels like sand being poured into my ears. * I find both 48kbps' and 64kbps' artifacting less annoying than 105kbps, even though 105kbps has a much more present high end. * 132kbps also sounds substantially better than it did before, but is still very "granular"; I might consider using it for some content, and feel it would be perfect for in-car listening. * 256kbps sounds transparent compared to PCM; high-quality mode sounds no different. * 352kbps sounds transparent compared to PCM; next to 256kbps there is no difference to my ears in quick testing. * 48kbps-base AAL is the same as other 48kbps, as expected * oddly, 352kbps-trancoded from 48kbps-base AAL sounds slightly clearer, but is still obviously coming from the 48kbps source, making use of AAL completely useless in my opinion - unless you use SS for general listening from your PC. * There was no noticeable difference in encoding times between "normal" and "high quality" modes, despite "normal" also being labelled, "(faster)" Totally Unscientific Conclusions: * 352kbps isn't sufficiently different from 256kbps to warrant using SS to transfer tracks for general listening. * I'll still be more likely to use HiSP or PCM than 352kbps, unless 352kbps is made accessible through Simple Burner. * The listening difference between normal and high-quality modes isn't substantial, but the encoding times aren't different enough to warrant using normal over high unless your machine is very slow. * LP2 sounds sufficiently better compared to my last tests with it that I'll likely use it to make discs for in-car listening in the future. * AAL is completely useless. If they made it so SS would transcode from the lossless copy to a chosen bitrate, it might have some use. * I'll continue using Simple Burner to copy my CDs for portable listening