garcou

"system file writing" is 10 -15 sec maximum.

Exactly the same for me with my nh900: only artist/track names when pressing display button on the cdx-GT700D car unit. Unfortunately, not any tiltle display on the head unit with Mz-rh710 , although it display tiltles on the md unit itself...

Sonicstage is windows 98se, 2000, millenium, nt, xp sp1, sp2, Vista compatible (4.3 version).... Personnaly I've just bought another pc and installed windows XP sp2, because I will never need vista. But even vista is compatible with sonicstage (4.3)...

thanksfully , I've got a nh900, but I'm disappointed that Mz-rh710 or rh1 will not display the titles even with an update of the connects2 adapter...

That's a pity Sony wasted time and money reducing the label screen size on the blue disc (after they wasted money enlarging the cases of the red one!). After that, they will say they have no money to make himd deck and car unit ! Something is going wrong in Sony's head...

At present , with at least 700KB/s (5600kbps) writing speed himd allows very good quality video: SQ quality in mpeg2 (standard quality of dvd video recorder: 2h/dvd or 25min/himd) and High definition in mpeg4 (I have copied a video from "National Geographic HD" on a himd: it plays it without any problem, and the quality is superb!). Try to put a 2h xvid encoded film on a himd: it will play very well...

thank you, BIGHMV. i will phone and try a firmware update. WoO: the connect2 box is made for(*) 1) controling FF/FW track of the md with the Cd car reciever 2) displaying the MD titles on the reciever screen. With my sony cdx-gt700d and mz-nh900 I have both of them, but only track and artist name (I need to push on "display" on the reciever to change from trackname to artistname). the notice of the box says to push "repeat" function on the reciever to display album name instead of artist, but it does'nt work. With mz-rh10/rh1/rh710 there's not any title...only the FF/FW control works. (*) Obviously the box allows to play the sound of the MD through the amplifier of the reciever! (the sound is very good, no lacks of power even with the headphones output because the boxe provides a little preamplification)

I've got the asonwhd001. With my NH900 I can see the artist/track (I need to push on display on the reciever to change from artist to track name) titles on my cdx-700d reciever, but not the album tiltle. With the second (rh10) and third generation (rh1) himd units , I only got the control, but no title! I remember to read on this forum or atraclife that the connects2 adapter needs an update for recent Sony portable units. Do you think it will fix the issue ?

I archiv my family photos on both DVD and HimD ( 1 per year). For my work , I save 3 times: 1 on PC an 2 on 2 different md ( I synchronize the 3 with "alwayssync.exe" software, freeware). DVD/CD are not convenient for dayly update.

Would somebody on this forum able to transform an old Sony mds ja ES into a himd unit (just changing the necessary parts)? because Sony seems uncapable to do this....

Yes I have the Rh1, and others... I use himd as usb mass storage for my work's files, family photos and little videos. To read them I need a computer. I use himd with sonicstage for music: the songs are payable on the unit itself on the move, or through a computer with sonicstage interface. This way you cannot play the music files using windows explorer, although you can see the folder himd hifi with 8 esoteric files inside: don't touch them and you'd better hide the folder with windows folder options...Anyway this is not a big problem, because you can upload-download- upload again the audio files without any limitation or degradation to original computer but also any other computer (with sonicstage installed on it...). Of course you also have the possibility of putting music files through explorer, just like for photos, .doc etc... but yes each method is invisible to the other (except the " esoteric" himd hifi folder which you cannot make anything) Sony said this to prevent you from buying the unit... It used to be some viao with an integrated MD bay, but never heard of himd bay... Recently, I made a post that could interest you: http://forums.minidisc.org/index.php?showtopic=19582 regards.

1) yes, except net-md(lp2/lp4 atrac3) tracks that have been transfered from computer with sonicstage (with simple burner ,you can!). Yes , you can convert to wav. No more copy protection for Pcm/atrac3+/SPatrac analogue, digital-optical or digital-USB ! 2)Wav yes , mp3 yes (sonicstage put them in one large file on th disc but doen't reencode to atrac).No, but you can format your old 74/80min disc into 291MB hi-MD! 3) you can transfer audio files, just like computer files with explorer, but you will need a computer to read them with the player of you choice (wmp, wiamp, etc...) 4) Yes: you can upload tracks to a different computer: no more copy protection. 5)Mz-rh1 was specially designed and configured for live recording... 6)We are all dying a little more, day after day...When you choose a car you think: "is it good for what I need?" not wonder "will it be dead technology, one day"...

first post edited concerning Simple burner

sonicstage will not let you convert wav64(high/low) to another bitrate, but it is possible with a track uploaded from MD. If you don't remember in what bitrate you had encoded your minidisc, I've just try this to see what would happen. But it is not very usefull, I agree with you

Really, no one has the solution ??

First post has been edited ...

I understand your problem... Can I suggest you try to ripp in AAL a whole CD of Classical or Live and then render to wav, then transfer to MD or burn a CD ... and see if the gaps are acceptabl for you? Good luck!

I think we have to be clear in what we are talking about. I propose that we adopt these nomenclature for future dicussion: Rippxx: ripped in lossy xx kbps atrac from CD into SS RippAALxx : ripped in AAL xx kbps from CD into SS High : high quality normal : normal quality Conv : converted to MD xx: transfered to MD with specified bitrate then uploaded back to computer (after deleting the original file in my library) MD Stand : transferred to Md without conversion then uploaded to computer (after deleting the original file in my library) As some files are OMA encrypted or have not the same apparent bitrate - 256 vs 64 kbps- all the files are supposed to be converted to wav to see they real nature These files are equal byte for byte (I mean audio bytes - the gap can differ) to full 16 bits 44 khz pcm original wav : rippWav rippALL64normal(convWav) rippALL64high(convWav) All these files are equal byte for byte (I mean audio bytes - the gap can differ) to 64 kbps high quality lossy atrac: ripp64high(convWav) rippAAL64highConv64(convWav) rippAAL64highConv256(convWav) rippAAL64highMD256(convWav) rippAAL64highMD256conv256(convWav) rippAAL64highMDstand(convWav) rippAAL64highMDstandConv64(convWav) All these files are equal byte for byte (I mean audio bytes - the gap can differ) to 64 kbps normal quality lossy atrac: rippAAL64normalconv64(convWav) rippAAL64normalConv256(convWav) rippAAL64normalMD256(convWav) rippAAL64normalMD256conv256(convWav) rippAAL64normalMDstand(convWav) rippAAL64normalMDstandconv64(convWav) wavConv64(convWav) wavMD64(convWav) wavMD64conv64(convWav) these two files are different of the others and different of each other: (certainly reencoded) rippAAL64highMD256conv64(convWav) rippAAL64normalMD256conv64(convWav) As you can see, Stormshadow , rippAAL64highConv256 (as rippAAL64normalMD256) , is fake 256, but original high64kbps (not 256 rencoded; it is funny to see the OMA file structure:if original rippAAL64high is DATA1DATA2DATA3DATA4, rippAAL64highConv256 is DATA111111111DATA2111111111111DATA311111111111111DATA41111111111, just to fit the apparent size of 256kbps!! I agree with you that ripping a whole CD in ALL will introduce different gaps that the original wavs (except for the first track), when converted to wav. But the audio bytes are identical (just their adress have change because of the gap: you can show it by applying a constant offset to all bytes adress with a program like hexcmp. But the simpliest way is to use audiograbber " file comparaison tool " : it is capable to only compare the audio bytes of the two wav files whatever gap difference beetwen them) Although, I've still not tested them, I think the conclusionw will be the same with other bitrates. For me, the point is now to determintate if non-sonicstage lossy (HI-SP 256kbps or HI-LP 64 kbps) is equal or not to Sonicstage 256kbps or even 352 kbps (high and normal quality): for example : is HiSp(Onkyo2xspeed) > ripp352high ?

what do you mean? can you explain a little more?

What do you say ???? I've just have a look at sony japan, and it is not true: http://www.ecat.sony.co.jp/walkman/lineup.cfm?Series=MD and sony china: http://www.sony.com.cn/electronics/P_audio...md_CHS_HTML.htm

What I have tested and can certify for 64 kbps: Ripp: ripped from CD into SS High : high quality normal : normal quality Conv : converted to MD xx: transfered to MD with specified bitrate then uploaded back to computer MD Stand : transferred to Md without conversion then uploaded to computer (as some files are OMA encrypted have not the same apparent bitrate - 256 vs 64 kbps- I converted the whole to wav to see they real nature) All these files are equal byte for byte (audio bytes) to 64 kbps high quality lossy atrac: ripp64high(convWav) = rippAAL64highConv64(convWav) = rippAAL64highConv256(convWav) = rippAAL64highMD256(convWav) = rippAAL64highMD256conv256(convWav) = rippAAL64highMDstand(convWav) = rippAAL64highMDstandConv64(convWav) All these files are equal byte for byte (audio bytes) to 64 kbps normal quality lossy atrac: rippAAL64normalconv64(convWav) = rippAAL64normalConv256(convWav) = rippAAL64normalMD256(convWav) = rippAAL64normalMD256conv256(convWav) = rippAAL64normalMDstand(convWav) = rippAAL64normalMDstandconv64(convWav) = wavConv64(convWav) = wavMD64(convWav) = wavMD64conv64(convWav) these two files are different of the others and different of each other: (certainly reencoded) rippAAL64highMD256conv64(convWav) rippAAL64normalMD256conv64(convWav) as you can see, Stormshadow , rippAAL64highConv256, is fake 256, but original 64kbps (not 256 rencoded; it is funny to see the OMA file structure:if original rippAAL64high is DATA1DATA2DATA3DATA4, rippAAL64highConv256 is DATA111111111DATA2111111111111DATA311111111111111DATA41111111111, just to be the apparent size of 256kbps!!

I've made byte for byte comparaison with hexcmp.exe . (Audiograbber and EAC also have usefull byte for byte comparaison function, but only for wav) With this program you can compare not only size, but also the itags part of the files and the audio part of the files. It also allows to apply a constant offset to all bytes (samples) address, that way you can correct gap or itag position at the beginning or the end of the file. It is an hexadecimal so mathematical, not listening analysis: if two files are identical (at least the audio parts) listening test is useless- the files will sound the same ; if the audio parts (after gap or itag correction) are different, a listening analysis will be necessary. hardware: dell dimension E520; Sony dvd+/-RW AW-Q160S drive Sonicstage: 4.3 For recordings without Sonicstage ( non-USB digital recordings) it would be better to use the drive of the computer, but my soundcard has no digital output. So I’ve used : - optical recording : Sony CDP-411 cd deck + MZ-RH1 - direct digital recording (real time and 2x speed) : Onkyo X-B8 bookshelf I can affirm: 1) Wav files: a) Ripping a non-scratched CD track ( I will try scratched latter) into WAV, using EAC, Audiograbber or Sonicstage 4.3 will result in exactly (byte for byte) the same .wav files. b ) Transferring a wav file to MD then uploading to computer (gives an encoded and copy protected OMA pcm file) and converting it to wav, will result in exactly the same wav file . c) non- sonicstage recordings : - optical pcm recording uploaded to computer than converted to wav gives a different file that the wav file ripped with Sonicstage (or audiograbber, EAC,..) : although applying a gap correction at the beginning and the end of the file, the audio part bytes are different. I’ve made a time analysis of the wave with EAC, and it appears that the two waves are almost the same but the optical wave has a kind of jitter which makes progressively change the samples position when time is running. The maximal derive is 0.02 s. so I think it will not do big listening issue. - realtime pcm recording using CD->MD copy function of the Onkyo X-B8: same result that optical recording: the audio part of the wav-converted file is definitively different of the computer ripped wav. - 2x speed pcm recording using CD->MD copy function of the Onkyo X-B8: Great surprise ! the audio part of the wav-converted file (except the very little beginning and end for a gap or trackmark slightly different) is byte for byte identical to the computer-ripped wav! - As this is a bit confusing, I’ve made the test a second and even a third time : always the same result! And more : the realtime(although digital) copies are different of each other ; at the opposite, 2x speed copy renders always the same file!! Conclusion: only the 2x speed copy is like data computer transfert; realtime copy is like optical, subject to jitter and unconstant. For happy owners of the onkyo bookshelf: if you want a perfect digital copy of your CD, use 2x speed, not realtime! ( with DLA(peak search) disabled) (don’t know if it is the same with sony CMT-AH10…) It will be interesting to test this with lossy atrac copy , but as speed has influence upon quality of lossy encoding, the analysis will be more complicated…. 2) Mp3 files Transfering an mp3 track to MD with sonicstage ,then uploading back to computer, will result in the exactly same mp3 audio file (only the itag position has been changed by sonicstage, the audio part is identical) 3) Atrac Advanced Lossless (AAL) files a) Ripping the same CD track into AAL with different associated lossy bitrate will result in different (non-copyprotected) OMA files (different sizes, different itag parts, different audio parts) but when converting it to wav, it will result in the same wav file that the directly ripped wav file, whatever bitrate (64;128;132;256;352kbps) or quality (high/slow or normal/fast) you choose . So AAL is really lossless whatever associated lossy-part bitrate or quality you choose. b ) High quality AAL CD-ripped OMA file and normal quality AAL CD-ripped OMA file with the same associated lossy bitrate are different: the itag part of the file is almost the same (bytes 0-570; 0.01% of the file) but the audio part ( bytes C79-1827100 for example; 99.99% of the file) is totally different. (the high quality file is always larger than the normal quality file- except using 132kbps associated lossy bitrate (atrac3 instead of atrac3+) ). c) You have no choice when converting in “my library” a wav file into AAL: it will always result in normal quality with 256kbps lossy-part associated bitrate. This AAL file has the same audio part (byte for byte) that the normal quality 256kbps CD-ripped AAL file (only the itag part are slightly different. Note that the two files have the same size and are both not copyprotected ). d) Transfering whatever AAL file to CD-audio with sonicstage, then ripping the burned Cd to the computer will result in exactly the same original wav file. e) I assume that ripping a whole CD in ALL will introduce different gaps that the original wavs (except for the first track), when converted to wav. But the audio bytes are identical (just their adress have change because of the gap: you can show it by applying a constant offset to all bytes adress with a program like hexcmp. But the simpliest way is to use audiograbber " file comparaison tool " : it is capable to only compare the audio bytes of the two wav files whatever gap difference beetwen them) conclusion : These files are equal byte for byte (I mean audio bytes - the gap can differ when ripping a whole CD) to full 16 bits 44 khz pcm original wav : rippWav rippALLxxnormal(convWav) rippALLxxhigh(convWav) * 4) Lossy Atrac (Atrac) files I think we have to be clear in what we are talking about. I propose that we adopt these nomenclature for future dicussion: * Rippxx: ripped in lossy xx kbps atrac from CD into SS RippAALxx : ripped in AAL xx kbps from CD into SS High : high quality normal : normal quality Conv : converted to MD xx: transfered to MD with specified bitrate then uploaded back to computer (after deleting the original file in my library) MD Stand : transferred to Md without conversion then uploaded to computer (after deleting the original file in my library) HiLP: non sonicstage 64kbps lossy atrac (example optical recording) HiSP:non sonicstage256kbps lossy atrac (example optical recording) As some files are OMA encrypted or have not the same apparent bitrate - 256 vs 64 kbps- all the files are supposed to be converted to wav to see they real nature first conclusions: a ) All these files are equal byte for byte (I mean audio bytes - the gap can differ) to 64 kbps high quality lossy atrac: ripp64high(convWav) rippAAL64highConv64(convWav) rippAAL64highConv256(convWav) rippAAL64highMD256(convWav) rippAAL64highMD256conv256(convWav) rippAAL64highMDstand(convWav) rippAAL64highMDstandConv64(convWav) b ) All these files are equal byte for byte (I mean audio bytes - the gap can differ) to 64 kbps normal quality lossy atrac: rippAAL64normalconv64(convWav) rippAAL64normalConv256(convWav) rippAAL64normalMD256(convWav) rippAAL64normalMD256conv256(convWav) rippAAL64normalMDstand(convWav) rippAAL64normalMDstandconv64(convWav) wavConv64(convWav) wavMD64(convWav) wavMD64conv64(convWav) c ) these two files are different of the others and different of each other: (certainly reencoded) rippAAL64highMD256conv64(convWav) rippAAL64normalMD256conv64(convWav) As you can see, rippAAL64highConv256 (as rippAAL64normalMD256) , is fake 256, but original high64kbps (not 256 rencoded; it is funny to see the OMA file structure:if original rippAAL64high is DATA1DATA2DATA3DATA4, rippAAL64highConv256 is DATA111111111DATA2111111111111DATA311111111111111DATA41111111111, just to fit the apparent size of 256kbps!! Although, I've still not tested them, I think the conclusionw will be the same with other bitrates. For me, the point is now to determintate if non-sonicstage lossy (HI-SP 256kbps or HI-LP 64 kbps) is equal or not to Sonicstage 256kbps or even 352 kbps (high and normal quality): for example : is HiSp(Onkyo2xspeed) > ripp352high ? ****Special simple burner (2.0)**** SBpcmMD(convWav) = rippSSwav (only the gap differ) SBhi-spMD(convWav) = rippSS256normal(convWav) (only the gap differ) SBhi-spMD(convWav) and rippSS256high(convWav) are distinct audio files That confirms that SB lossy is not high quality (but SB can copy protected CDs, SS not ) To be continued…later…perhaps in September !

To compare byte to byte Two files imported/created/converted/transfered/uploaded with sonicstage, you can use this programme (15 days shareware): hexcmp take care: the audio data is not the first bytes( those are the itag data) . you have to go down in the file, after some lines of "0" you also can compare two wav files, byte for byte with Audiograbber (freeware) No, you must make an error . I've tested it with Hexcmp and audiograber: the two files are identical, byte for byte HexCmp2_Setup.zip agsetup.zip

No, you must make an error . I've tested it with Hexcmp and audiograber: the two files are identical, byte for byte

To compare byte to byte Two files imported/created/converted/transfered/uploaded with sonicstage, you can use this programme (15 days shareware): take care: the audio data is not the first bytes( those are the itag data) . you have to go down in the file, after some lines of "0" you also can compare two wav files, byte for byte with Audiograbber (freeware) HexCmp2_Setup.zip agsetup.zip