dex Otaku

Really? I've been hoping for this as a feature since v2.1.

Um. You aren't the -actual- Tom Ellard, are you?

gloomy gus and knightsdir: Not to be rude, but you might try reading the entire thread first. You might also try the search engine, looking at the "view new posts" page [link at top of every page], and looking under the relevant subfora for topics relating to what you're askng about. To answer directly, again, for the billionth time [prominent stickied FAQs on the subject notwithstanding] .. NO, you can not upload MD or MDLP recordings. See also this recent thread: http://forums.minidisc.org/index.php?showtopic=14120

The main differences between the regional versions of SS are in where they point the Connect portion to. If you don't use the Connect, store, it's nothing to worry about. I'm in Canada, and since mid-2004 I've used versions from the US, Canada, Asia-Pacific, and Europe. I've never had a single issue related to regionalising.

Well put .. my thoughts: First, it was a retrofit. This means that for backwards-compatibility purposes, it had to not change the current data structure so much that it wouldn't work with older units. Second, this kind of protection can be easily accomplished through, say, adding a few extra bits or using unused bits in the TOC for each track, identifying their source and copiability. As for the actual data stream on playback [and during storage], SCMS can handle the job; one way to tell if this is the case would be to try copying an MDLP recording via optical means that originated with SS and using an SCMS stripper. If with the stripper, copying is allowed, then we see how weak it is. If without the stripper it doesn't, then the old rules are all that's really being used [aside from the retrofit hack which would be part of every unit's firmware enabling identification of the originating source as a computer or not]. My understanding was that there's a qualtiy difference on par with SP vs. LP2 [i.e. a faster padded-out LP2 codec being used] when using the high speed method. I might be wrong, though. I sort of doubt this, though it's possible. And as for the hardware uploading issue, yes, it certainly would be possible. My understanding of the Dolby liscensing issue is that it came up because Dolby patented something that referred to basically .. a lossy codec that doesn't suffer terrible degradation in the signal after multiple generations of encoding/decoding/encoding. Sony were working on ATRAC at the time, and rather than poison their product with a patent lawsuit they just paid Dolby. ATRAC itself isn't using anything from Dolby, AFAIK. That said, a software codec would still involve liscensing because of that patent. Which means it would cost money .. on the other hand, Sony are already distributing versions of WMA and MP3 with SS, which they'd still have to pay for. They would even have to pay if they chose to distribute with LAME, contrary to what most people think. IMO, the MD / netMD question is completely moot. The following is pure speculation and may be out to lunch [i have no desire to dl all the service manuals and compare components for every model]... The development required to alter all netMD units would total in the thousands of man-hours - how likely is it that the firmware in every netMD unit even comes from the same base source, or that they even all use the same hardware? Basically, they'd have to design for and test every unit they want to retrofit independently, or per model-family, and that's even making the assumption that the firmware is upgradeable in every model. HiMD is only 2 generations and less than 10 models in .. that would be a much smaller task, comparatively. The base components in all units are the same, so aside from the interface which varies model-by-model and display-by-display, the changes would be pretty minor compared to attempting the same with netMD. My suggestion to Sony would be this: [go ahead and call me nuts] Release a 3rd gen of HiMD, including at least a couple of deck models that include both SP/DIF and USB functionality. Fix the MP3 bug. Give users a way to lock manual levels controls on. Give users back the function of being able to pitch or speed-alter playback. Enable the alternate bitrates for recording. And lastly, add USB uploading on all models for MD/LP tracks. And maybe, just maybe, get someone who actually uses the units to rearrange the menu architecture so that the most commonly-used functions are really fast to get to, rather than having to dig through levels after level and re-enter the menus again after changing a single option. I don't find that much fault with the HiMD units I use as they are; the list above I think are the most important changes to make. Many of you will disagree, of course. Lastly, I wish they would do with HiMD what I've been saying since it was introduced: market it as a recording medium, not a portable music player. MD and netMD are dead on the water in that market, and HiMD is far too little, too late, to make any difference to their marketshare. Their hdd players fill that role to compete with the iPod and whatever else - on their own merits. Whether they're successful or not is topic for another discussion elsewhere. HiMD is inherently extensible between generations. The fact that they added native [though somewhat crippled] MP3 playback in gen2 speaks to this; there's no reason why they can't go even further, and do things like add fast lossless codecs, 24-bit recording, &c. As with the MP3 issue, it means losing bits of backward-compatibility, but - really, how many people are buying these to use exclusively as players? The majority of MD and HiMD enthusiasts are amateur or professional recordists who need something extremely portable and at relatively low cost; HiMD fits that bill nicely, and it does its job admirably well IMO. The fact that it plays music it still only a bonus feature for me; if I really wanted a portable player, I'd buy a hdd-based unit. But then, I'm one of those old people who likes devices that are designed to do one thing, and do it well. Like .. a cel phone that is a good phone, not a camera/music player/phone/organiser and all of them shoddily done. I know, I'm a dying breed. This may be true, but MD itself is 14 years old. Development, from my understanding, has been frozen for some time and will go no further [though this doesn't mean that new hardware won't be made, it just means no changes to the format and how it functions]. The advantages of MD over HiMD are honestly few, and the only truly significant one IMO is the difference in battery life. HiMD plays all the old discs in any case. There's basically no reason for them to waste their money making new equipment that really serves a fairly small market to begin with, and which is shrinking every day. I've said it before, and I'll say it again, even though it's still not official: IMO, MD and netMD are deprecated. Haha! I forgot about that. Thanks.

If it were really planned obsolescence, why wouldn't they provide a method that is as simple as possible to get data -off- the media they're planning obsolescence for?

The codec itself would probably be the least of the work.

I didn't make any steadfast recommendations above, but I'm with A440 on this. HiMDRenderer will do what you need in a single step [though I'd note that titling the tracks on the recorder using SS beforehand is a good idea], and for lectures, MP3 exceeds the quality you really need while giving you the smaller filesizes you want in order to give copies to your students or colleagues.

Give the current state of DRM in SS 3.4, that can't be the reason any more. There are still other things to keep in mind though, which I did already touch on above, but didn't fully address. The main one is that the software governing HiMD hardware [i.e. the firmware] would have to be updated to allow MD/LP uploads. This in itself would not be a trivial task; firmware is written at low-level, using hardware directly, so any additions such as this would not merely be a bugfix [as was the case with the missing letters on the RH10 titling interface] but an actual majour change to the communications interface - a whole new module just to address the one use. That means programming it, and using more resources to store the firmware on every unit. I have no idea how much space the current firmware takes or if there is any room left to really add majour functionality changes, so it's possible that current [G1 and G2] HiMD hardware might not be upgradeable at all [though I doubt it, myself]. It also means developing the ATRAC SP codec and altering the HiMD modules in SS to interface with the new firmware. Basically, adding what many of us think is a simple change would actually be a fair amount of work. I think it would be worth it, though; how many MD users out there want this function? Probably almost every single one who bought into HiMD, at the least; there's also all the broadcasters and colleges out there still using portable MD recorders or who have archives of recordings they'd probably really like to back up by other means for long-term safekeeping. Hey - if Sony want a guinea-pig, they can call me with my NH700. I'll find another machine to beta SS on, even. I'd do product testing for them at the drop of a hat.

FFDshow isn't a codec pack. It's a single integrated interface for multiple OSS codecs. A codec pack is a conglomeration of multiple codecs, all of one version, sometimes but not often current compared with the date of compilation. They often contain multiple redundant codecs and ones that override other that the average Windows system already comes with, and which usually do a better job left alone. Basically: if what you want is to downgrade independent codecs that you've installed yourself [such as DivX and XviD video codecs], and to cause problems, go looking for a codec pack. On my system I have the following installed: * PowerDVD with its associated hardware-capable MPEG2 codec and AC3/DTS decoders [which I don't use] * The most recent stable build of the Koepi XviD codec [used for encoding only] * FFDshow With that combination, I have the best possible XviD encoding, along with hardware MPEG-2 support, and dshow support for ogg, flac, mp3, ac3, DTS, h.264, XviD, DivX, MPEG-1, MPEG-2, MP2 audio .. you get the picture. FFDshow, by itself, covers basically everything that I ever need to use with directshow support. WavPack is a notable exclusion, so I have the official version of that as well, but for nearly all audio playback I use Foobar2000, which has its own codecs. I also use VideoLAN Client which has internal OSS support for nearly all the same formats; coincidentally, many of its codecs are the same ones used by FFDshow. FFDshow in terms of audio gives me basic EQ and effects for playback [i usually only have EQ on for room resonance correction], along with 24-bit decoding of basically all audio formats it supports. I have never had a problem using FFDshow with SonicStage. In fact, the one change I noticed after switching from the FhG codec was that SS stopped having any issues with VBR MP3s.

If the card's mixer applet itself doesn't let you specifically select SP/DIF as a recording source, then you're probably out of luck. You might try doing a search on google for something like the model # and SPDIF or SP/DIF or even SP-DIF. There might be other fora out there with information on alternate drivers or possible hacks to get the interface to actually do the job it's supposed to. Backups made by digital or analogue means? If they were optically-made copies, then yes, they'll be protected by SCMS. I can't say for certain whether your sound card respects that, though, assuming you find a way to actually make it record using SP/DIF.

I'm not sure what options MM offers for recording source [it depends on both the recording software -and- the audio drivers you're using] but have you tried any software [Audacity I'm relatively sure supports this] which allows you to select a recording source independent of the system mixer? You should be able to [assuming the audio drivers support it] select "SP/DIF in" as the recording source. Using "system mixer" might not work because, as a source, it means "what you hear through your speakers is what you will be recording". Many drivers with digital inputs [or ones for many ASIO supported cards with analogue inputs] won't let you -hear- the input unless you turn on monitoring - and, funnily enough, once you turn on monitoring in the system mixer, it usually defeats the ability to record from that input [because with monitoring on, it's already active]. So, here are my suggestions in short: * leave monitoring off in the mixer app * if monitoring can be turned on in the recording app, it shouldn't affect things * see if you can select the SP/DIF input independently in your recording app Also note - many sounds cards with SP/DIF inputs don't respect SCMS. Some ignore it completely and allow anything to be recorded; some ignore it completely and don't allow anything to be recorded; and of course, some respect it. If the recordings you're trying to copy from the deck are 1st-generation analogue [i.e. recorded live on your MD fom a mic, or recorded from any analogue source] they should be copiable according to SCMS rules. Recordings made from an extrernal DAC usually should be copiable this way, too [from pro DACs they should actually be marked as completely unprotected]. Recordings made from a CD player via optical in should not be copiable by SCMS rules.

I will get to doing some test uploads ASIC. Things I will test for: * uploading of unmodified tracks in HiLP, HiSP, and PCM modes * handling of tracks with known write errors [known problem] * handling of tracks that have been edited on the unit [known problem * handling of very short track lengths [known problem] * handling of contiguous tracks recorded via line-in and automatically trackmarked by the unit [specifically, whether combine still has the repeated section issue, which is admittedly likely a hardware problem] * exact behaviour of SS regarding attempts to upload non-DRM'd tracks from different sources [i.e. user-recorded original, SS transcoded from MP3, SS encoded from CD, SS encoded from WAV] If anyone can add any suggestions to this, please do.

Just some thoughts after reflecting on the some of the misconceptions expressed in this thread.. * MD/LP does NOT use encryption of any kind [it uses a proprietary data structure related to that of CD's] * MD/LP does NOT use DRM other than SCMS [which is easily defeated] * ATRAC [292kbps SP mode] itself does not currently exist as a codec on the PC, not even in Sony's [formerly Sonic Foundry's] professional software [i.e. Sound Forge, which has netMD support built-in and has for quite a while]; an actual ATRAC SP codec would be needed for anything to advance, not that this would actually be difficult to arrange * There is no actual reason, hardware-wise, why MD/LP recordings can't be transferred digitally to a computer; there are no limitations imposed by either the media or the data format themselves, though the hardware would have to be made to support the option, which it currently is not. This would likely require firmware upgrades to enable the option, assuming the added code would not inflate the firmware beyond the size limit imposed by the hardware in the units * [opinion] Sony made a deliberate CHOICE not to support MD/LP uploads because it does not use modern DRM * Until SS 3.4, SCMS itself was not even respected by SS [i.e. not checking of SCMS bits during upload of optical recording to mark tracks as eligible for conversion to WAV or not] Most importantly: * Considering the recent changes to OpenMG DRM, especially concerning the uploading of user-made recordings, there is now NO REASON for Sony to not enable uploading of MD/LP recordings

http://forums.minidisc.org/index.php?showtopic=10621 Scroll down to "MP3 Playback Test" It's beyond me how any device decoding a bitstream of any type could end up with a "filtered" profile that so perfectly matches something done intentionally. That said, it can be compensated for fairly well with the EQ if you know the curve and how to use an EQ.

My apologies for the rash generalisation calling users stupid.

What kind of TV is this? I've never seen a TV with digital audio outputs on it before. Aside from which .. TV audio from digital recievers can be in multiple formats, including MP2, AC3 [dolby digital], and PCM [which is the only format your MD can understand].

Please go to the reviews forum and peruse the reviews of the RH10. Mine in particular has graphics explaining why this is.

This varies market-to-market, country-to-country, even. I think that "content distributors" would be more accurate than creators. While artists on majour labels may or may not suffer lost sales rom unauthorised distribution of their works by internet, the ones who really lose in the traditional system are the distributors and the backers - not the artists. Here in Canada, the vast majority of musical or sound artists are independents who have no access whatsoever to formal distribution chains. I have yet to meet a band that wasn't signed to a majour label up here who aren't taper-friendly and who don't actually not take issue with their works being ripped and distributed on the net - in fact, the vast majority of bands I've come in contact with since the 'net really took hold openly support their works being distributed on filesharing networks and the like. The plain truth is that for bands who are out on their own [not being backed monetarily, marketed, and distributed by a majour label] having their content available on the 'net means their potential audience increases dramatically. As a result of more people hearing their work, they actually sell far more albums than they would otherwise. The part of the DRM argument that I personally feel the vast majority of people simply don't get, and this includes the majority of bloggers and journalists who defend one side or the other, is that while the RIAA and other various groups may state that artists benefit from the use of DRM, that is an outright lie outside of the majour-label system which represent an extremely tiny minority of the actual recording musicians on earth. The distributors and publishers [record companies] are the ones who stand to benefit, while the artists simply get shafted as usual.

tekdroid - just a note to say .. you hit that nail right on the head.

Digital Rights Management. In the fantasy world of the RIAA, what DRM means is that the record company and not the end user retains control of how any given track can be copied and/or distributed. In Sony's world [as with most current commercial forms of DRM], DRM means lock-in; you're stuck in a closed system, depending on one company's software to store, play, and copy tracks to a player, and depending on that company's players. As SonicStage [sS] has progressed, Sony's DRM has relaxed considerably. Generally speaking, successful DRM means the inability to make 1:1 copies of things digitally beyond a certain number of generations or outside of the closed system of a single piece of software and line of hardware. Any methods that are not already allowed by library software like SS involve either transcoding [converting to another format digitally] or copying in realtime via analogue means [the "old way" of doing things, as with tape recorders]. In either case, some form of generation loss takes place, meaning the copy you end up with is degraded to some degree compared to the original it was copied from. For curiosity's sake, trying googling [with the quotes] "analog hole" or "analogue hole". Back up your library using the SS backup tool [it's in the menus], download the v3.4 installer, and it should remove the old version automatically during the installation process. I have upgraded SS numerous times on my own machine and never had it eat the existing library or cause issues surrounding "invalid rights info", but I seem to be in a relative minority of users who will actually confess to having had SS usually work properly for them [most people only say anything about SS when they have issues with it not working]. If all goes nominally, upgrading SS should not harm your library. That said, I have always run the SS backup tool before upgrading, even though I've never found it necessary to restore the backup afterwards. Better safe than sorry. Yes. That is the usual purpose of installers - to install something, or if necessary to upgrade what's already there. First, I'd suggest reading through The HiMD uploading FAQ [which will be updated to reflect changes to SS 3.4 shortly]. Once you have converted your recordings to WAV, you can do with them as you will - including editing them, backing them up asis, and transcoding them to another format that consumes less space. WAV files themselves should be playable in literally any media player supported on the Windows platform. There are numerous other formats that consume less space than PCM WAV, though. What format to choose depends on several things including your space requirements, accessibility/format ubiquity, whether you need the original recording saved without quality loss, and if the answer to that is no - sound quality preferences. Many of us here choose to store our "masters" in lossless formats such as FLAC or WavPack [both free/open-source], and even WMA lossless. The advantage with lossless formats is that you can save 30-50% of the space required to store WAV files, with no quality loss whatsoever. Tracks still end up fairly large compared to MP3s, but this tends to be the chosen method for backing up originals so that an exact copy of the source is always available for future use. Codecs for various lossless formats come as plugins for most popular audio players, or are included with them. As their use is not as widespread in general or supported natively by hardware, they do not however make ideal formats for sending to other users who are likely to want something they can simply play, rather than having to install additional software in order to do so. For distribution, lossily-compressed formats like MP3 are far more practical. MP3 in particular may not be the best-sounding format in terms of how its losses work, but it definitely is king of the hill in terms of ubiquity - any computer newer than about 1996 [regardless of operating system] can play MP3s with the right software, most portable players support the format natively, and many newer car CD players and nearly all newer DVD players will play MP3s from CD- or DVD-Rs you make yourself. I personally do not advise storing your master recordings in any lossy format [with the exception of cases where the original recording was in the lossy format you're wanting to back up]. The extra space used is well worth the advantage of having an exact copy of the original should the need arise to re-encode it to another format or bitrate [size/quality], and especially if you need to edit the recording later. GIGO. I'd recommend downloading marcnet's HiMDRenderer, which will let you convert tracks directly from your SS library or from the discs themselves to MP3, FLAC, &c. This is by far the simplest method of converting tracks in your library to MP3 to send via email. marcnet has his own thread on the fora here about HiMDRenderer. I'll leave discussion as to what the actual "best" format and settings are to someone else. OMA [previously OMG] files are Sony's proprietary container format for audio. These are the files that are both generated and used by SonicStage, usually encoded in some variant of ATRAC3 or ATRAC3plus. Generally speaking, OMA files are usable only by people running SonicStage, which makes the format an extremely poor choice for distribution even though it is possible to use it for such. Side-note: those aren't HiMD discs. They're standard MD80s, and if they were recorded on an RZ700 then they are definitely not in HiMD format. See here. This is another thing you can use HiMDRenderer for. The only way to copy tracks from a legacy MD or MDLP recording using your portable is via the analogue route - using appropriate standard audio cabling [3.5mm male to 3.5mm male stereo, or TRS, cable], connecting the headphone out of your player to the line input on your computer's sound card, and using recording software on the computer. HiMDRenderer removes most of the hassle from doing this by controlling your player and starting/stopping recording on the computer so that the tracks on your hard disc match closely [though not perfectly] what's on the original MD. Last things last - please don't take this as an outright admonishment, but I'd would like to point out that the threads I've linked to are stickied [i.e. very easily found] in the relevant fora. Cheers.

Good to see more positive changes. I hope some of the install and stability issues brought up by many of our users have been addressed as well; many of them are just plain weird, and it seems to me like 3.3 had many more than the previous versions. Interesting that they can suddenly make 192kbps work on HiMD. Glad to see full support for uploading/exporting optical recordings. Expect another update to the text of the HiMD uploading FAQ. Suggestions for additions or changes should be PM'd to me, please.

Edit: Having read all of your linked posts/threads, I only saw a ocuple that were even near-legitimate claims of data loss. The rest were -all-, without exception, people who did not learn how to use their hardware and/or software and lost data [or experienced the inconvenience of having to re-rip full libraries] as a consequence - most notably, the "An Anthropologist’s worst nightmare: DRM" post. Your petition has almost no legitimate claims to support it. That's kind of a shame, since Sony have actually paid attention to multiple specifics of our wishlists on this forum in the past, implying that at least sometimes they do actually listen. Your boycott isn't really about SS, when it comes down to it; it's about DRM, and the difficulties it causes for users who are basically too stupid to research what they're buying before they buy it, read their Fing manuals, or click "help".

darian: While I somewhat support your idea in spirit, I'm taking note of the fact that the majority of complainants you've linked to from the site are actually people who did not use the product properly, not people who are experiencing bugs. Sony's DRM [which has been relaxed substantially in 3.x versions, contrary to one of your linked posts] is designed specifically to stop moving tracks from one copy of SS to another. Why people should expect anything other than "blocking" behaviour when they're obviously not RTFM or basically learning how to use the software as intended is slightly beyond me. There are people out there with real claims to SS being destructive to their data/audio. Perhaps if you linked to people with actual problems, rather than people who don't invest the time to learn how to use the hardware and software as intended and designed, your argument would be more legitimate. At the moment it fails almost completely in that department.

If you have ffdshow installed and it's newer than mid-2004, don't worry about it. What A440 is implying [that all versions of ffdshow cause problems with SS] is patently false.