dex Otaku

Sorry to disappoint you, but what you're experiencing is one of the side-effects of DRM - it doing its job. The music you ripped from your own CDs was keyed to the specific installation of SS that you were using. Trying to simply move them, without using the SS backup tool, to another installation of SS can't work because SS can tell the music originated somewhere else. I'm not aware of any way for you to transfer the liscenses without having the original installation of SS around to make a transferable backup from.

g8rken - Both? I'd expect that the non-LCD model doesn't [since it has no display]. Be warned that attempting the record with a mic while a remote with display is plugged in is next to useless because the sound of the display updating will be picked up by the mic cable.

GIGO - Garbage In, Garbage Out. Reiterated: you can't improve on what's not there. When you convert MP3 to any lossless format, all yuo're doing is basically testing the quality of the encoding, for one, and of the decoder you're using, for another. Whatever artifacts were in the file to begin with will be in the lossless file afterwards. There are times when transcoding can be done more easily from a CD image than from individual files. One example of this is if you have a CD image in MP3 format with a cuesheet; the cuesheet will allow you to make a CD with the same loayout as the original, and the fact that the MP3 is a disc image [a single contiguous file that has all the audio from the beginning to the end of the originating CD with no gaps] allows you to make a gapless CD [or CD image to mount and rip with SS] despite MP3's general non-conformity to the same framelength as CD. While I've never used MP3 files this way, I've used disc images sourcing from FLAC and WavPack files to make gapless HiMD copies. Basically, with any format that your CD writing software can understand but SS can't [which covers a lot of ground], whether a disc image or not, sometimes it's just the most convenient way to get things to a HiMD or MD - rather than converting those files to WAV, importing into SS, transcoding, &c. In many cases it's really just a matter of preference which way you go; the end results will be the same.

In my first post, I used the phrase "lossless packing". This is synonymous to "lossless compression". At no point did I mix "wavpack" annd/or "flac" with the term lossy. Incidentally, WavPack also does lossy encoding, with the option to make a supplement file that will make it lossless again if the two are used together. This is not the mode I use for archival, which is lossless, and therefore doesn't alter the signal but reduces the amount of space required. * compression != loss. Compression is squeezing something into a smaller space. The general term does not imply loss in any way whatsoever. "Audio compression" blankets both lossy and lossless methods, as well as being a general term for a type of dynamic range processing [compressing the dynamic range]. "Audio compression" also is often mistaken to mean or to imply loss because the average consumer, like you, didn't even know it was something desirable until the most common forms of it were lossy - in the form of DTS, ATRAC, MP2 and MP3, and AC3 for beginners. The reason you are mistaking my language is because you have accepted the term to imply loss, which is false. There are many forms of lossless compression. One is used in DSD streams on SACD. One [Meridian Lossless Packing] is used by DVD-Audio. These are systems, like WavPack, FLAC, shorten, WMA lossless, Apple lossless, APE, and OptimFROG which are able to compress - not reduce, but compress - a digital audio stream without there being any signal loss in any way. All digital audio compression, lossy or not, is a form of data compression. I started using more specific terms because obviously using the blanket term that people have come to associate with lossy compression was not clear enough for someone who doesn't know that it doesn't imply lossy compression. Christ. Agree to disagree - okay, I'll do that. It doesn't change the fact that you're still wrong. It wasn't a quality debate, either. Lossless packing algorithms are lossless - so there's no quality loss. You can't seem to get that, though, and you appear to refuse to actually educate yourself on the subject. Have a nice day.

I have been using my ears as a recording and live sound engineer on and off for about 14 years. I programmed computers for years, and later became a hardware tech. I've also been around satellite TV distribution systems since I was about 7. University I got bored with. Broadcast college I got bored with. Audio Engineering college I had to quit because of a 3,000km move. Perhaps some of this gives me the background to understand the difference between data compression and data reduction. Please, do scroll back up and read some of the wikipedia articles about the various codecs. Or go to the codec websites. Or maybe study computer science and English until you can understand the difference between compression and reduction. Take your pick. You are quite plainly a git, but hopefully you can learn at some point.

Oh my god. I give up. This will just devolve into insults if I don't stop now. The fact that I'm correct apparently makes no difference.

Okay. I'm trying, really really hard to be nice about this. There is a reason it's called lossless. It works a bit like how zip or rar compression works - you remove redundancy, analyse for patterns &c. and reduce them, and store the compressed version. On the output end, you decompress the data to get back out *exactly* what you put in. Bit for bit, word for word, every single bit of audio data that goes into the encoder comes out of the decoder exactly the same. This is not a lossy perceptual coder. This is not based on data REDUCTION, but data COMPRESSION. What goes in is exactly what comes out. mm'kay? To reiterate, that means that the output of the decoder is identical in every single way to the PCM data that went into the encoder. Every sample in the same spot, every amplitude identical. There is no loss. Period. Hence LOSSLESS. Quality is 1:1, PERIOD. Please. Wrap your head around this. If you don't trust me as a source of information, try reading some of the following: http://en.wikipedia.org/wiki/Flac http://en.wikipedia.org/wiki/Wavpack http://en.wikipedia.org/wiki/Category:Loss...sion_algorithms

It's interesting how the different ways people do things end up showing different problems in software. I've never experienced any problems either with WAV export or HiMDRenderer, but then, I don't use methods like letting SS export automatically upon the completion of an upload. The destination folder for my exported files changes every single time I do any exporting [because I like to organise things a certain way], and I tend to dislike any function that goes ahead with further steps without my telling it exactly what to do. This is the same reason things like Firefox's downloads automatically being set to the desktop drives me batty - I prefer being asked where I want something put, so I know exactly where to look for it later, and aside, the desktop is not a place to put files IMO. I don't even have more than 3 prog icons on mine [i do use Objectdock, though]. At the least, in this case it's clear what you're doing [differently from me] that is getting you such different results. The fact that you've been able to trace the problem to a certain number of possible causes is excellent, as well. Thanks for the info.

Uh. What part of "lossless" are you not understanding? lossless packing = exactly the same quality, sample-for-sample identical playback as LPCM. The key differences between lossless-packed formats and LPCM: * lossless-packed formats can contain error-correction and still have less overhead; this means they can be streamed over network pipes with fewer errors, and still use lower bandwidth, with exactly the same output, bit for bit, at the receiving end * they take up less storage space and use less bandwidth regardless of error-correction and metadata [and even DRM], with exactly the same output on playback

I don't *keep* anything on HiMD. Once it's uploaded and converted to WAV, the original disc is wiped. Part of the reasoning behind this is that for me, $11.99 locally for discs is expensive. Until a week ago, I had only one 1GB disc, the one that came with my NH700 in August of 2004. I have been reusing that one disc for over a year with no problems that weren't either caused by user error or SonicStage, which has improved sufficiently that I haven't had it corrupt a recording in quite some time. As for storage: DVD-R fills my needs. I have redundant backups of almost everything I've worked on since about 1997 or so, and I refresh them occasionally to make sure the original media is both working still and replaced with newer copies. Cripes, I even have nearly all of my sent and received email since 1998, active in Thunderbird as we speak.

I actually prefer the overall sound of my NH700 to my RH10 [same digital amp as RH910]. The RH10 has a rise in the high end that seems to oversweeten the sound a bit for my liking. The NH700 has less output volume, certainly, but - it also has flatter frequency response, despite having a standard A/D system and analogue amp. The overall effect of the RH10 is to exaggerate compression artifacting, unfortunately. The slightly fuzzy analogue nature of the NH700 smooths out the same defects that are plainly obvious on the RH10. That said, I use my RH10 for listening for far often than my NH700 because of its MP3 support.

I have two challenges to this: FLAC and WavPack. Both feature good lossless-packing ratios, embedded cuesheet support, corruption-resistance/error correction, sample-accurate positioning within files, and full metadata support. FLAC has some hardware playback support as well. Both are open-source, and as such conversion tools that enable trancoding to any other format are both easy to find and free. Also, in terms of download sites, I'll remind us all of archive.org. Plenty of concert recordings, documentary stuff, copyright-lapsed audio and video, &c. downloadable in multiple formats [often including lossless]. A great number of recordings there are even originally from MD and HiMD.

Of the units I've used, my favourite was the R-37. Metal case, 2-AA batteries with good headphone volume, straight ATRAC SP recording/playback, buttons/switches for the majority of functions, manual levels could be entered just by holding the record slider for 2+ seconds. The only real fault I had with it was END SEARCH. Otherwise it performed beautifully and was nice to handle. There's an R-37 sitting at the pawn shop down the street from me and I've been tempted to try and find the money to get it [they want $100 for it] .. it's been there for months and no one's ever touched it.

I ran some tests to check out 352kbps, importing WAV directly from CD just as you did, and on 6 tracks from 6 different CDs, did not experience this issue. I also ripped the same 2 tracks >10 times to different bitrates and had no problems there.

RE: what format SS converts to when you're importing from CD - there's a button at the right-hand side there, between the CD import window nd the library window .. that lets you select what bitrate to import at. You can choose atrac3, atrac3plus, WAV, MP3, or WMA formats in various bitrates. The button looks a bit like a cassette tape, and under it displays what format and bitrate are currently selected. See here: If you click that button, you get a dialogue like this: I would have used attachments here, but I'm not allowed to.

[insert sound of "wrong answer" buzzer] I don't know of -any- standalone D/A units with straight digital outs that don't mark their stream as SCMS '00' [copy allowed, first gen]. All digital recorders should respect this. Legacy MD equipment does [even consumer portables] as does DAT. The way the SCMS bits SHOULD be recorded by -any- digital recorder should be identical whether you're using internal DAC or external DAC via SP/DIF. The generation is the same either way. I agree that HiMD likely doesn't record SCMS information at all - only source type. This is where Sony have utterly violated the long-standing rules of copy "conduct" that people have lived with for 15+ years.

Qwakrz: While I agree with you in principle, there are exceptions to this. M/S stereo [the type of joint stereo encoding used by most lossy codecs] is optimal for use with 2-channel sources that have a high degree of coherence between channels - i.e. much is the same in each channel, such as most vocal tracks in music recordings and other things you could consider to be monaural [hence the M in M/S - mid/side] in the mix. One encoded channel contains coherent signals [M] while the other is incoherent signals [s, out of phase signals]. [Yes, I'm oversimplifying this, but you'll see the general point in a moment] The big advantages to this method are - 1, If a mono signal is recorded, 100% of the alotted bitrate can go to just the one signal, rather than half to each stereo channel in the case of discrete stereo encoding, and 2, phase coherence between channels should be more easily maintained. There are times when this is NOT what you want, though - such as if you are recording 2 channels that have little or no coherence between them. An example of this would be recording from two separate lapel mics during an interview; the level of coherence [at 0 degree phase diff as well as 180 degree phase diff] should be pretty close to zero at all times. Discrete stereo coding with this signal would be more efficient and likely less artifacted. Just my extra $0.02. Cheers.

It could be a little of both. Another case in point: if you record on HiMD using an external D/A convertor jacked into the optical input, you can upload but not export this recording with SS. If HiMD/SS were respecting SCMS' rules, the fact that this is a 1st-gen recording [0th-gen copy] should make it copyable after-the-fact. This is a clear violation of SCMS.

Good points. I hadn't thought of it in exactly that way. I've been thinking of the copy made during upload as a 1st-gen copy [2nd gen recording], the export as the same generation, and anything after as 2nd gen copy [3rd gen recording]. Thanks for the jog to the senses. Point though: HiMD bookshelf systems, for instance, won't allow copying via SP/DIF regardless of the recording-generation on the disc [1st-gen analogue or anything else]. [That the same units disable SP/DIF completely during HiMD playback is sort of irrelevant; if you put a 1st-gen analogue-sourced recording in there, you should be able to copy it digitally via SP/DIF under the old rules.]

SCMS has been included in consumer digital audio equipment since about 1990. The DMCA basically stripped SCMS of any merit. Most current consumer devices no longer follow its rules because they are considered too weak. SCMS != modern DRM.

My RH10 puts out just below 1Vp-p with a full-scale recorded signal, volume at 29/30, and EQ disabled. This would be comparable to the line level signal put out by most cassette decks, but less than HiFi VCRs, CD Players, &c. I use both my RH10 and NH700 with people's stereos fairly regularly, and aside from having to turn the volume up louder, have no actual complaints about quality. If the amp you're jacking into happens to be of spectacularly poor quality, you might run into hiss issues, but these days that's actually a pretty rare find even with relatively cheap equipment.

This is part of why OMA is relatively useless as an archival format. The only safe way to back up your own recordings is to convert to WAV, and either back up those files or transcode them to a lossless packing format and archive those.

What are the uncopyable files? What is the source format, specifically, including encoding type and sampling rate?

My NH700 works fine in the same way. Odd, maybe.

The differences in compression are pretty minimal, really, i.e. <5% difference nominally. For really large files, that can make a fair difference, though. I still use FLAC over WavPack for distro CD images because the tools I've found are better for dealing with FLAC with embedded cuesheets than for WavPack. WavPack in its newest incarnation compresses slightly better [maybe 2% on average] than FLAC, but the real reason I ended up switching was when I was encoding 32 hours of 16-bit audio to compressed formats .. the WavPack encoder is somewhere between 5-15x faster than FLAC on my machine.