ATRAC Advanced lossless real quality

[alexis]

I have made some posts in this topic and I would like to catch the attention of some of you guys about making some advanced measurements on WAV files rendered from AAL format (using SonicStage 4.3).

I already found out that AAL files behave differently regarding to conversion to other formats, and I have done some basic analysis (well, means just "look at the WAV with HEX editor" and "do some hearing tests") which tend to show that AAL does not reproduce source material identically, but may show no loss of source material information, maybe something like reproduce an identical frequency distribution, or something like that.

However, I lack the hardware, software and expertise to perform such nice analyses and comparisons like some people made here to compare the various Hi-MD formats. Could somebody perform some tests and publish them in this forum? I would be very interested, and maybe others too, as it seems that AAL is not really popular, according to the relative rarity of posts on this subject.

[raintheory]

Keep in mind that the inclusion/removal of id tags (which might happen when converting to AAL) can change the MD5 checksums of WAV files... While not necessarily changing anything about the audio data itself.

EDIT: I'll see if I can help out with some frequency analysis figures from Soundforge

Edited July 23, 2007 by raintheory

[raintheory]

As a test I took the original test WAV file and used GoldWave to perform a phase inversion on it. I then mixed that with the WAV file created from the AAL file and the result was silence. So yeah it's identical, as it should be considering it's lossless. It also kinda sucks as a lossless format, FLAC compressed the same file a good bit better.

Bear in mind that AAL isn't transferred to Hi-MD as AAL, but rather as whatever you have specified in the Advanced section of Transfer Settings in Sonicstage.

Below is a frequency analysis of the original WAV vs the AAL WAV:

AAL is shown in red

WAV is shown in green

As you can see, the audio is identical (the green is completely in line, and underneath the red)

Edited July 23, 2007 by raintheory

[Sparky191]

....it seems that AAL is not really popular, according to the relative rarity of posts on this subject.

Because its useless for HiMD users and other Sony Devices. Though I've seen some comments that you can use it on some of the Sony NW-S700 players. Dunno how true that is. I like to know about the NW-A800.

You would have to use SS as your main application for managing your library, if you used AAL. Personally I wouldn't risk it. Besides FLAC is a more useful format for archival.

Edited July 23, 2007 by Sparky191

[garcou]

I have made some posts in this topic and I would like to catch the attention of some of you guys about making some advanced measurements on WAV files rendered from AAL format (using SonicStage 4.3).

I already found out that AAL files behave differently regarding to conversion to other formats, and I have done some basic analysis (well, means just "look at the WAV with HEX editor" and "do some hearing tests") which tend to show that AAL does not reproduce source material identically, but may show no loss of source material information, maybe something like reproduce an identical frequency distribution, or something like that.

However, I lack the hardware, software and expertise to perform such nice analyses and comparisons like some people made here to compare the various Hi-MD formats. Could somebody perform some tests and publish them in this forum? I would be very interested, and maybe others too, as it seems that AAL is not really popular, according to the relative rarity of posts on this subject.

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)

Hi!

I have been testing those ATRAC3plus and AAL formats, and there is a difference, definitely. Funny thing is, converting a WAV file into an AAL 64kbps and rendering this AAL into a WAV file leads to... a different WAV file - so much for being lossless.

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

Edited July 24, 2007 by garcou

[Richard]

* Moved to Software Discussion section

[alexis]

Thank you for your help. I am happy to observe that AAL seems to be lossless indeed - now I'll have to find out why I do not get rendered material identical to source material . Considering the results of your measurements, I will certainly use AAL as a format for my music library, although you do not recommend it. But I think the versatility of AAL in SonicStage makes it the right candidate for my intended use of a music library (keeping source material ready for conversion and transfer to various NetMD and Hi-MD equipment, as well as occasional CD burning). Anyway, it is only original CDs and a little bit of eMusic. I actually never listen to music using my PC, and now that I have lost one Hi-MD (I mean lost - I can not find it any more ) and my RH-10 has trashed a MD full of CD recordings , I am considering building a library to be able to replace such losses quickly.

I think I would use 64kbps AAL, as mos tof my transfers are for mass-storage music Hi-MDs. However, I want to be able to transfer some selected pieces at 256kbps, for favourites listening, and I would like to burn CDs in CD quality for use in Cd equipment or in car-stereo CD changer. So if the quality of the converted higher bitrate tracks and of the burned CDs is confirmed to be higher than the 64kbps quality, then AAL will do the job for me.

[RoGeR]

Sorry for a newbie question, but WHAT IS AAL? I've read about it, but never got round to understanding it. What I do recall is that it encodes in 2 parts, a "transferable" part and another part which builds it up to lossless? So, err... what happens when I listen on my PC.. and when I transfer to my atrac devices?

[Sparky191]

My undersntading is as follows. I could be wrong, so correct me if so. AFAIK there used to be a bug with it, dunno if its still there. Perhaps the bug as been fixed. Say you record AAL 64kbps. It records two parts. All in the one file.

{(Part 1- Lossless) + (Part 2 - 64kbps)}

If you play it on the PC it plays part 1. Lossless. You can only play lossless on the PC nothing else can play it.

If you transfer it to HiMD as 64 kps it transfers (part 2. 64kbps) without re-ripping it. Result 64kbps.

If you transfer it to HiMD as 132 kps it transfers part 2. 64kbps. it transcodes it to 132kbps Result dire quality.

If you transfer it to HiMD as 256 kps it transfers (part 2. 64kbps). it transcodes it to 256kbps Result dire quality.

If you transfer it to HiMD as 356 kps it transfers (part 2. 64kbps) it transcodes it to 354kbps. Result dire quality.

So basically its usless, because it transcodes the lossy part when you pick a rate other than lossless or 64k to transfer.

[RoGeR]

Sparky, that kinda made sense. But then again, why bother if you cant do anything else with the lossless bit? I would've thought that it saved the lossless part in the folder and transferred the 64kbps to the HiMD device, then say.... later, if I wished to up the sound quality, I could transfer say at 292kbps and it would merely encode from the lossless part?

[alexis]

My undersntading is as follows. I could be wrong, so correct me if so. AFAIK there used to be a bug with it, dunno if its still there. Perhaps the bug as been fixed. Say you record AAL 64kbps. It records two parts. All in the one file.

{(Part 1- Lossless) + (Part 2 - 64kbps)}

If you play it on the PC it plays part 1. Lossless. You can only play lossless on the PC nothing else can play it.

If you transfer it to HiMD as 64 kps it transfers (part 2. 64kbps) without re-ripping it. Result 64kbps.

If you transfer it to HiMD as 132 kps it transfers part 2. 64kbps. it transcodes it to 132kbps Result dire quality.

If you transfer it to HiMD as 256 kps it transfers (part 2. 64kbps). it transcodes it to 256kbps Result dire quality.

If you transfer it to HiMD as 356 kps it transfers (part 2. 64kbps) it transcodes it to 354kbps. Result dire quality.

So basically its usless, because it transcodes the lossy part when you pick a rate other than lossless or 64k to transfer.

Well, that was exactly the statements I was trying to clarify: is it really so or it is a legend? From the previous measurements, it looks like at least .WAV renderings from AAL are performed using the lossless part. So why not assume that conversion to other formats also uses the lossless part of AAL as source? Then, AAL format would be useful, because there is no loss of quality when converting to higher bitrates or burning CDs. I actually never have found any proofs that converting from AAL 64kbps to higher bitrates leads to loss of quality, just rumors. I can assure you that converting from AAL 64kbps and ATRAC3plus 64kbps does not produce the same results, regarding to "gaplessness". Let us try and experiment a little bit more until we have facts that we can analyse.

[alexis]

Sparky, that kinda made sense. But then again, why bother if you cant do anything else with the lossless bit? I would've thought that it saved the lossless part in the folder and transferred the 64kbps to the HiMD device, then say.... later, if I wished to up the sound quality, I could transfer say at 292kbps and it would merely encode from the lossless part?

I think that is what AAL does indeed (it still has to be scientifically proven). Conversions from AAL are performed using the lossless material source. AAL can then be considered as a lossless representation of source information, equipped with a "preview", or "thumbnail" feature in form of a smaller, lossy part that enables quick operation when lower quality is acceptable. For me, it is the feature I always wanted to have for such a music format: scalability. Maximal fidelity to source material, and fastest conversion (i.e. no conversion necessary) to "standard use" devices. A multi-step scalability would be even more desirable (say, information that stack onto another, like lossless over 256kbps over 64kbps), as I don't see perfect quality as a goal per se, but rather flexibility and ease of use for everyday life use.

[RoGeR]

Hmm stormshadow... maybe I'll try encoding an album tonight in AAL and see what happens when I vary the bitrates with each different transfer. To be honest, I've never even attempted AAL after reading so much about its supposed crapness.

If you're certain it behaves like what you've mentioned, then I'm all for it.

[Sparky191]

Sparky, that kinda made sense. But then again, why bother if you cant do anything else with the lossless bit? I would've thought that it saved the lossless part in the folder and transferred the 64kbps to the HiMD device, then say.... later, if I wished to up the sound quality, I could transfer say at 292kbps and it would merely encode from the lossless part?

The suggestion is that is not meant to work that way, but its a bug that not been fixed.

A year or more back there were a few threads on this and someone did some tests. I can't find them now but I do remember someone testing it at the time. I remember asking about it when 4.2 and 4.3 were released was this fixed but noone knew. Someone posted that one Sony Flash player supported it. Since then we've seen Sony drop ATRAC on devices like B100, and some seen some new iPod related products. But nothing more about ATRAC Lossless. I can't imagine its got a future myself.

[alexis]

Bad news guys: I have done some testing recently that definitely shows that although rendered WAV files and burned CDs are identical to the original (see this topic), when converting an AAL 64kbps file into an ATRAC3plus 256kbps file, only the ATRAC3plus part of the AAL file gets used to perform the conversion, that is the converted 256kbps file has the same quality as a 64kbps file (to be honest, the standard warning from SonicStage has always told us so). Combined with my previous observations, this leads us the following bottom line(s):

• AAL is useful for burning CDs or rendering WAV files
• AAL is not useful for converting to higher bitrates
• AAL helps converting high bitrates to low bitrates better (preserves gapless tracks)

So in conclusion:

AAL can be useful as format for your music library, but only if converted with high bitrate on your computer. The only drawback would be that files converted to lower bitrates would be converted from the lossy part of the AAL, not from the original (if somebody can actually hear the difference between 64kbps converted from original material and from ATRAC3plus-SP, except for gaplessness, this person should be called either God or The Nitpicker).

I think I'm going to build up my library with Hi-SP AALs, these are good enough for me (burn CDs, convert preserving gaplessness) and eat up less space on my hard disk.

See you guys for the next measurements... (next chapter is whether rendered files are identical when rendered alone or together with other files).

[Sparky191]

How did you confirm this by the way?

Did you do a blind test between

AAL > 64 kbps

AAL > 256kbps > 64 kbps

Its transcoded and from a lower quality file.

[alexis]

I converted source material (the overture of the nightmare before Christmas soundtrack) in AAL 64kbps, transferred it to minidisc as ATRAC3plus 256kbps and re-transferred it again after having deleted the AAL at 64kbps (because SonicStage uses the track's key to identify it, renaming or changing the album name of the track have no effect: SonicStage knows that it already has the track in the library, so it does not transfer it back). Then I rendered the transferred file into a WAV and had a look at it.

Typically, forr any track that begins with silence and rising music, the beginning of the WAV file is filled with zeros, and then very small amplitude samples begin to appear (FFFF,0001, etc...). At 64kbps these very small amplitude samples are removed, thus reducing complexity, so when comparing two files, it is easy to see which one shows these samples and which one shows zeros at the same place.

Maybe I will care doing a blind test between tracks transferred from AAL 64kbps and ATRAC3+256kbps at 64kbps, but I think I would not hear any difference (except, as I already said in previous posts, for the gaplessness).

Edited July 28, 2007 by storm shadow

[Sparky191]

Kudos for doing the the test Storm I've been very interested in this for while but never had time to check it out. Have to say that I usually can hear the different between 256 and 64 especially in music I know well. For pop stuff it may not be a big deal, or obvious that quickly. But if its guitar stuff or classical where I know it very well I well notice it pretty quickly. Theres a kind of a swirl to the sound, almost like a Doppler effect. I don't use the best of gear either.

[RoGeR]

Thanks for the test storm! Sad to hear this really!? What were they thinking when they developed the codec!!?

[Sparky191]

Thanks for the test storm! Sad to hear this really!? What were they thinking when they developed the codec!!?

Its not a flaw with the codec. Just a mistake the programmer made when he was coding it. I'm surprised it got through testing and QA though. I'd say it would be easily fixed if you had the source code. Unfortunately they've taken to long to sort it out.

[Strungup]

Its not a flaw with the codec. Just a mistake the programmer made when he was coding it. I'm surprised it got through testing and QA though. I'd say it would be easily fixed if you had the source code. Unfortunately they've taken to long to sort it out.

That was well spoken

[alexis]

More conversion Voodoo:

1. gapless?

   Gapless tracks are preserved when transferring imported tracks "as-is" (which is normal and expected) but only converting from 64kbps AAL to ATRAC3plus 256kbps preserves gapless tracks. All other conversions I have tested (AAL 256 -> A3+ 64, or any AAL to ATRAC3) causes slight gaps in converted recordings. Why does it work differently for this conversion? And will the 256kbps converted track have better quality (this topic seems to have been negatively answered according to our previous tests).

   However, looking at the re-rendered WAV files from these tracks (AAL64kbps->A3+256kbps->WAV) shows less differences to the original than the re-rendered 64kbps WAV file (AAL64kbps->WAV). Why? Beats me...

2. lossless?

   I can confirm after more testing that a rendered WAV file from an AAL track is identical to the original only for the first converted track. All following tracks show differences. Why? Beats me...

This unpredictable Voodoo has killed my confidence in the AAL format. Now I am stuck at the beginning of my survey: how will I build a music library which can handle multiple formats and multiple bitrates gracefully?

The only alternative I have is:

• import music as WAV files and let SonicStage perform conversions to other formats
  • good: simple library structure
  • bad: eats up disk space, must specify transfer bitrate using options
• import music multiple times into the library under the same album name and use playlists to manage the different formats and bitrates
  • good: no conversion voodoo, saves disk space, simple transfer handling
  • bad: inelegant and tedious library management, takes more time to rip and import music

Good advice, tips and tricks from anyone to manage a library using multiple formats and bitrates?

Does anybody know if a playlist can be generated outside SonicStage?

[Sparky191]

What you are trying to do in AAL is already possible using other lossless formats. The Apple Lossless, FLAC, etc etc. Using iTunes or MediaMonkey (My fav) you can have a library in lossless and on synch with a portable device. Transfer and encode on the fly the lossless to a compressed bitrate as it transfers. (I'd love to see ATRAC and Sony Device support added to MediaMonkey.) With MM I was able to do with with iPods and Creative devices, and also filtree devices like my Samsung.

You can do kinda of a manual version of the above though. The following is only my own method, I don't use lossless but it might give you some ideas. Its only from memory as I don't have SS installed on this machine. I only use SonicStage to transfer files to and from my HiMD. Convert to and from ATRAC. Etc. I don't use it to manage a library. I use MediaMonkey as it works well with tags and filetree and you can switch and correct tags from filetree and vice a versa. Its not perfect, but I like it. I find I get encoding errors using MediaMonkey so I don't use it to encode. Just to manage my library. I haven't heard/read anyone else having encoding problems with MM so YMMV.

When I open my SS its empty. I have no library in it. So I drag a folder or files (using explorer) from my main library on drop them in the open window in SS. Mine are MP3's. (a compromise I'm happy with) You can do this with multiple albums and tracks. Then I select all tracks and make them a compilation. Seems to group them correctly even though most of them are not compilations. Then I transfer/convert the files and delete them from SS.

You could do the same with FLAC. Convert them in MediaMonkey to the SS folder to WAVs. Import them or drop them on SS. Then transfer and encode them to HIMD on the fly. I think I tried this before, and because using MM I could name the folder and wav files as I wanted, (some applications are not as powerful as MM with file and folder renaming) SS imported the names/albums correctly. But it was a while ago so I could be wrong on the details.

Buy a TB HDD and save in .wav; .wav files have been with us since ages and will still be for quite a while.

I'm a fool but (will) do both: real-time or half-time dubbing via Hi-MD decks & bookshelves systems to Hi-SP on Hi-MD discs. Sorted by artist, with the odd compilation of course. Just for the sake of being able to edit on-unit if wanted, & also because I add way more track information than what GraceNote CDDB provides by default. AND saving on my dedicated ChronicStation... when I'm back afloat to acquire it... : (HDC-1.0 + >1TB USB 2.0 HDD)...

If you have the money and the equipment and time. Obviously theres no better SQ than everything in lossless. Anything else is compromised.

No tagging with WAV though. Which is a big issue IMO. Playlists, grouping by genre, albums, year, chronological order. Stuff like that. Another disadvantage to using WAV and to some degree Lossless, is that every transfer takes a lot longer because you are moving and encoding vastly bigger files. One of the reasons I compromised on MP3 was to speed up the transfers and backups. I'm moving a lot less data and hardly ever converting/encoding data. That I don't want to speed a lot of money on big disks was another consideration. If I really want a lossless version I can just pull out the original CD which is my lossless archive of sorts. I burn all my recordings on to CD as an archive/backup. But at the end of day I accept its a compromise compared to a digital lossless library.

[Sparky191]

...Aren't the .wav files in SS taggable?! I thought I had a few in .wav, with all their tags...

No. The info is stored in the SS database. Theres no tag info/meta data in wavs. One big advantage of lossless like FLAC and similar. Tags.

[garcou]

More conversion Voodoo:

1. gapless?
   Gapless tracks are preserved when transferring imported tracks "as-is" (which is normal and expected) but only converting from 64kbps AAL to ATRAC3plus 256kbps preserves gapless tracks. All other conversions I have tested (AAL 256 -> A3+ 64, or any AAL to ATRAC3) causes slight gaps in converted recordings.
   
   I can confirm that gap can slightly change with conversions.
   
   
   

   More conversion Voodoo: And will the 256kbps converted track have better quality (this topic seems to have been negatively answered according to our previous tests).
   However, looking at the re-rendered WAV files from these tracks (AAL64kbps->A3+256kbps->WAV) shows less differences to the original than the re-rendered 64kbps WAV file (AAL64kbps->WAV). Why? Beats me...

   1. 
      that's impossible! : (AAL64kbps->WAV) is identical to original wav (lossless); (AAL64kbps->A3+256kbps->WAV) is fake 256kbps lossy atrac: in fact true 64 kbps lossy atrac
      
      

   I can confirm after more testing that a rendered WAV file from an AAL track is identical to the original only for the first converted track. All following tracks show differences. Why? Beats me...

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

[alexis]

that's impossible! : (AAL64kbps->WAV) is identical to original wav (lossless); (AAL64kbps->A3+256kbps->WAV) is fake 256kbps lossy atrac: in fact true 64 kbps lossy atrac

I sais "re-rendered", I meant transferred to minidisc then transferred back to the library after the original material has been deleted then re-rendered as WAV file. So the quality/complexity of the lossy part can be evaluated.

[garcou]

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 ?

Edited July 30, 2007 by garcou

[alexis]

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 fit the apparent size of 256kbps!!

This would explain why the conversion rippAAL64high -> 256 is still gapless: it is exactly the same data as the (gapless) original import. All other conversions include gaps (which makes them unacceptable for me, as quite many of my CDs have seamless tracks (techno mixes, live performances, some classical, some soundtracks...).

I am afraid I will soon stop testing so much about AAL, because now I have ruled out the format as a choice for my library (mainly because it is not really scalable, ignoring the lossless part for re-encodings, and because of the broken gapless playing).

[garcou]

This would explain why the conversion rippAAL64high -> 256 is still gapless: it is exactly the same data as the (gapless) original import. All other conversions include gaps (which makes them unacceptable for me, as quite many of my CDs have seamless tracks (techno mixes, live performances, some classical, some soundtracks...).

I am afraid I will soon stop testing so much about AAL, because now I have ruled out the format as a choice for my library (mainly because it is not really scalable, ignoring the lossless part for re-encodings, and because of the broken gapless playing).

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!

[Sparky191]

I don't see why you have to make it so complex. If you encode from a lower bitrate to a higher one its the same data, it can't add detail that isn't there. if you then convert it to lower birate again, you are telling the software to throw away more data and make it smaller. So changing the data for the worse. I'm guessing the difference between high and low quality, is very little in both quality and speed so anyone who can be bothered will default to high. If you have to spend a lot of effort to tell one birate from another, the difference isn't worth bothering about in the real world.

At the end of the day its not the bitrates that are the problem here. Its SonicStage poor design, and programming bugs. So what should be simple is convoluted.

[alexis]

I don't see why you have to make it so complex. If you encode from a lower bitrate to a higher one its the same data, it can't add detail that isn't there. if you then convert it to lower birate again, you are telling the software to throw away more data and make it smaller. So changing the data for the worse. I'm guessing the difference between high and low quality, is very little in both quality and speed so anyone who can be bothered will default to high. If you have to spend a lot of effort to tell one birate from another, the difference isn't worth bothering about in the real world.

At the end of the day its not the bitrates that are the problem here. Its SonicStage poor design, and programming bugs. So what should be simple is convoluted.

The "bitrate" of AAL refers to the lossy part of an AAL file. I just had hoped that converting to higher bitrates would use the additional information (the lossless part) of AAL to produce a higher-quality file. I like sound quality, that is why I like the MiniDisc format. The other (and for me big) problem is the lost gapless playing: it is true that it may be very hard to distinguish a 64kbps ATRAC3plus converted from original material and the same one converted from 256kbps ATRAC3plus - but the converted result is not gapless any more, which I cannot tolerate, because gapless playing is one of the reasons I ditched my iPod for MiniDisc gear. I want gapless playing at any bitrate.

[Sparky191]

I was only comenting on the logic. AAL is flawed as its implemented now. Which is a pity. I thought iPods had gapless now?

[Sparky191]

...

You could do the same with FLAC. Convert them in MediaMonkey to the SS folder to WAVs. Import them or drop them on SS. Then transfer and encode them to HIMD on the fly. I think I tried this before, and because using MM I could name the folder and wav files as I wanted, (some applications are not as powerful as MM with file and folder renaming) SS imported the names/albums correctly. But it was a while ago so I could be wrong on the details....

Tried this and the Wavs aren't named correctly in SS. I thought it might be clever about the folder/file names. But it isn't.

[Sparky191]

Hi guys I've a new idea for you to test. I've only been messing around so i need confirmation that this works. I ripped a CD to WMA 9 Lossless. Corrected the tags in MediaMonkey then dragged them from MediaMonkey Or Windows Explorer onto SS and it imported them fine. Kept the tags etc. (You have to select all tracks and make them compilations to group them in albums). SS would convert/re-encode from WM9L to ATRAC as it was transfered to HiMD. You might like to test the WAV=WMA9L and WAV>ATRAC is the same as WMA9L> ATRAC. Etc. Apologies if I'd made a mistake somewhere.

So WMA9L might be useful as a Lossless library format for HiMD?

Edited July 31, 2007 by Sparky191

[Sparky191]

Seems to be some info about WMA9 being gapless with some software.

http://www.hydrogenaudio.org/forums/index....showtopic=52272

http://www.thedowerhouse.com/jukebox/qanda.html

Found some earlier topics on this

http://forums.minidisc.org/index.php?showt...13688&st=15

http://forums.minidisc.org/index.php?showt...pid=88783

http://forums.minidisc.org/index.php?showtopic=14042

Knew there'd been discussions on this before. I'm sure a search would reveal more.

Edited July 31, 2007 by Sparky191

[Qwakrz]

Trouble is that WMA9 is not gapless in sonicstage..... I dont know what they did to the decoder of the codecs in SS but its really poor.

I get some very small gaps between tracks from my WMA9LL album collection.

What I would really like is something like Daemon-tools that can mount a cue sheet of a flac CD image, this way I can use SS or SB to dump it onto a disc without gaps and at whatever bitrate I need at the time.