Hey what's up everyone! First off, I'm not a total noob so hit me with your best shot, fire away! I would say I am well versed in EAC, Cue Tools, Burrn, Accurip, Easy CD-DA extractor, Traders little helper, Flac.. Basically I use all these programs daily. My "audio collection" is all lossless, every CD has a proper log and cue file (non compliant), Artwork, Checksum, NFO, and Metadata. I don't know why I haven't ever installed Foobar 2000 but I haven't yet. I use WInAmp to listen to my music. I have a Creative Fatality sound card connected by toslink to my Harmon Kardon receiver, 7.1 Surround sound.

Here's my problem. I have an ipod Touch 32gb I've had for a few years. I have a really nice set of Shure ear buds for it and lately I've been using it more and more. Up until now I've been transcoding mp3's and loading them into itunes. It's getting to be a pain keeping two collections of music. Lossless and Lossy. I recently discovered I can add the ffmpeg encoder to Cue Tools and transode to m4a, it shows up as the Lavf52.34.0 encoder. What I like is that Cue Tools makes a cue sheet for the m4a just like it would for Flac (even though it doesn't work with m4a). It copies over the log, makes an accurip log, and even embeds artwork for the m4a. What I don't like is so far I haven't been able to decode the m4a using Cue Tools. However, I can easily transcode the m4a back to Flac using Easy CD-DA extractor. Actually, Easy CD-Da extractor would be perfect if it modified single file cues for me but it only creates cues, it doesn't work with them like Cue Tools does.

This is going to be a gigantic undertaking for me. The prospect or transcoding all my lossless music from flac to m4a, using the ffmpeg encoder within Cue Tools. Knowing I can use Easy CD-DA extractor to decode the m4a and still have a proper (non compliant) cue sheet, and log for burning Audio CD's. I haven't figured out how to make an NFO for the m4a yet, but there's no need for playlists and I can easily make an MD5.

The benefit to doing this is I will be able to load my entire collection into itunes and be able to listen to the beautiful lossless m4a on my ipod touch. At the same time, now I found a way to transcode the m4a back to flac if needed, maintaining a proper log and cue sheet. All with minimal effort. Of course file size is a small issue. The m4a is bigger then Flac level 8.

Any ideas? Thanks!

PS.. I really don't understand "Apple Lossless" Is that just a generic term for Lossless M4a? There are so many different lossless m4a encoders, are they all considered ALAC? This ffmpeg comes up as Lavf52.34.0, but it's still MPEG-4. How does is differ from Apple lossless? I can't find any info anywhere.

I too am a little confused as to why you would want the cue sheets to transfer over. Neither iTunes nor your iPod will be able to work with them. You can use a converter such as foobar2000 or even dBpowerAMP and all of your metadata and tags should transfer over (I know they do whenever I use dBpowerAMP to convert my ALAC files to mpeg-4 AAC with Nero).

As for your question regarding mpeg-4 lossless. To my knowledge, there is only one mpeg-4 lossless encoder/decoder and it is an open source project. Apple lossless (ALAC) is a proprietary Apple technology. Some programs (foobar2000, dBpowerAMP, etc.) can decode these files. Even fewer can actually encode their own ALAC files using reverse engineered code. Still, those fit ALAC standards and not mpeg-4 lossless. From what I have read, there is an ALAC ffmpeg encoder but it is far from archive use ready.

There is a program called XLD that batch convert from FLAC to Apple Lossless. dbPowerAmpo does that too. There is no need for cue sheet. iTunes and new iPods (last 4 years or so) can handle gapless playback. dbpoweramp and xld can transcode from a cue sheet + file to individual files.

My point was I do burn traditional audio CD's very often and even though the cue file with m4a extensions doesn't work with m4a tracks, it can easily be edited with Burrn to work with WAV's tracks, once I transcode the m4a back to flac again. I tried to explain that. Sometimes I feel I'm the only one who recognizes the importance of a proper log/cue file. You guys that download a single APE/Flac file and use medieval cue splitter, or some other garbage splitter, and delete the cue sheet are butchers imo.

Point is, if the cue sheets and logs had no relevance in my world, I would have made this transition long ago. The reason I have stuck with Flac is obvious, it's extremely easy to decompress and Burn an audio CD. Now that I found a way to do this more easily with m4a I just want to make sure it's not going to degrade the integrity of the source files. Make any sense?

Oh and when I say m4a encoders, what I mean is when I open a folder with Tag and Rename, the encoder. It only says Apple lossless if you use itunes. Otherwise it's a different encoder for every program I've used so far to transcode to m4a. ffmpeg shows up as Lavf52.34.0 and CD-DA extractor must be proprietary. I've seen Max.08.01, whatever that is.. I just wanted to know if there's any difference.

I had no problems burning audio CDs with iTunes from Apple Lossless files. As far as I tell iTunes to burn them gapless. I burnt some live CDs and I hear no gaps! Why don't you try it to find out if it works (for you.)Please note you have to set the burning parameters in iTunes to burn audio CDs WITHOUT gaps before doing so.

Can anyone tell me if there's a scientific reason not to use m4a to archive lossless audio? Using Cue Tools with the ffmpeg encoder. I read something about integrity checks? That's what I really need to know. I successfully took a single APE file, with embedded log/cue and ripped it into m4a tracks with a proper cue for individual tracks, gaps appended (I know it doesn't work for m4a, read on) Next I transcoded the m4a tracks to flac and edited the cue file accordingly. I then ran accurip and audio checker tests as well as TAU analysis and I see no noticeable loss in quality from the original WAV file. I even decompressed the flac and used EAC to burn an audio CD using the cue. I'm not that anal but I guess I could rip the wavs off this CD-R and see if it tricks accurip but that's not necessary.

I do appreciate your thoughts on gapless playback, honestly I never knew it was a problem for the ipod/itunes. I prefer the original CD sound when I burn CD's so having the original gaps is important to me. I use EAC to burn audio CD's.

Group: Members
Posts: 325
Joined: 17-October 05
From: United States
Member No.: 25178

QUOTE (RendoR @ Oct 16 2009, 19:51)

You guys that download a single APE/Flac file and use medieval cue splitter, or some other garbage splitter, and delete the cue sheet are butchers imo.

I don't know how prevalent you think this is at HA. In my experience, it's extremely limited. There aren't that many places to buy FLAC images on the internet. And the musical variety when you do is even further limited (in my experience, of course).

Can anyone tell me if there's a scientific reason not to use m4a to archive lossless audio?

You are mixing things up. m4a is just an extension that can house Apple lossless files, mpeg-4 lossless files, mpeg-4 AAC audio, and a series of other formats. You need to specify if you want to use Apple lossless (which will work with iTunes and your iPod) or if you want to workwith mpeg-4 lossless (which won't work with your iPod and iTunes). There is a big difference between the two as I have previously explained. Additionally, you can call Apple lossless as ALAC. No need to start throwing around the file extension as it is only confusing people.

Now, about your cue sheets. I think you need to drop them if you want lossless files that work with iTunes and your iPod. Many programs can burn audio CDs gaplessly without cue sheets. I think people who insist on using cue sheets, even with files that aren't meant for that, are stuck in the dinosaur ages. There, I tried name calling and look where it got me.

Our point is that, with ALAC files, cue sheets have no place. That is the simple and plain truth. You cannot use cue sheets with iTunes or your iPod so whats the point? You have to edit the cue sheet and convert the ALAC files to WAV before using them to burn an audio CD. I have burned standard audio CDs using ALAC files a countless number of times using iTunes without a single issue (with gapless music and music that had gaps in them). So why should anyone go through the trouble of using cue sheets with ALAC when it isn't supported? That is like walking around the Earth just to go from point A to point B when you could have just walked backwards for 2 miles.

Yes, my purpose is to have my lossless audio in a format compatible with my 32gb ipod touch. At the same time I want to be 100% sure the file integrity is intact, and I still have "Trader Quality" files. I'm looking for a faster, more efficient way to create ALAC files without using itunes. Being able to add tags and embed artwork at the time of encoding is crucial. I'm sure you guys are familiar with Cue Tools. It's a fantastic program. It's really no bother to create Cue sheets with Cue tools, it's automatic. Then with Burrn it only takes a second to change the extensions from m4a to flac or wav. You're right though, it's allot of trouble to trasnscode ALAC to FLAC just to burn a CD if you can do it within itunes. However, itunes has no adjustment for write offsets so if I burn a disc with itunes for archiving, then rip the tracks later on they won't be accurately ripped. Hard drive failures are a reality.

I understand regardless of the encoder used, ALAC is ALAC or lossless m4a. Like I said I'm using the ffmeg encoder with Cue Tools to transcode APE/FLAC to ALAC or lossless m4a. I tried using CD-DA extractor to transcode to m4a and when I transcoded it back to Flac for a test and there were major problems. FFP's were off and tracks were coming up as only partial matches in accurip. That's what I'm trying to find out, if transcoding to ALAC without using itunes could corrupt the source files in any way. So far the answer is a resounding yes. However I don't have that problem with the ffmpeg encoder, so far anyway.

I just always thought having a cue sheet with gaps detected/ gaps appended plus an extraction log was extremely important. People do put allot of weight into it. Are you saying that as long as you have an Accurip log plus Audio Checker that the Log/Cue aren't that important? I thought they showed origin.

Ok, then you need to use Apple lossless and stop looking at mpeg-4 lossless (there is no such thing as lossless m4a so stop using that phrase as it will only confuse you/me/us even more) as that will not work with your iPod or iTunes. Additionally, ffmeg's ALAC encoder is not archive use ready (unless something has changed). It is still buggy and should only be used for development and testing standards. You need to use dBpowerAMP if you want to convert your APE/FLAC files to ALAC.

Transcoding to ANY lossless format will not corrupt the source files. However, the resulting transcoded lossless files may not match up against the source lossless files when using a buggy encoder. Hence why you should stay away from the ffmpeg ALAC/lossless mpeg-4 encoder as it is not archive ready.

Cue sheets have their place. However, when it comes to iPods, iTunes, and ALAC files, they have no place. Trying to use cue sheets with ALAC files is like trying to fill up an unleaded gas car with diesel fuel; it just won't work. Cue sheets are no longer needed for proper gap detection, housing AccurateRip information, etc. Stick to using dBpowerAMP for ALAC encoding as it uses a solid ALAC encoder that has been extensively tested and is known to be 100% lossless (not all open source/third party ALAC encoder are truly lossless as they have errors).

Finally! Thank-You kornchild! I'm glad you understand what I'm asking, I think my wording has confused everyone. Now, getting down to the nitty gritty.. I have been using the ffmpeg encoder, which you say is buggy (you and others) I read something about length mismatches. Wouldn't a length mismatch cause Accurip errors though? In my experience, length mismatches cause tagging issues and even poorly ripped wavs will tag if the file lengths are the same. It's funny because I was reading that it's BD Poweramp that has the issues and ffmpeg is more stable.

I'm not trying to push the issue, but so far I have had nothing but success transcoding to ALAC using the ffmpeg encoder with Cue Tools. Accurip tests come back the same, and when I transcode back to Flac the FFP's are still good. I only do this for testing, not that I have any clue.. I just very convenient, and I absolutley love Cue Tools. DB is ok, I just find Cue Tools to be easier and I like the way it works. I'm listening to ALAC encoded with ffmpeg on my ipod now and it sounds great. No skips, pops, glitches. Seamless playback.

Can anyone confirm or deny the version of ffmpeg I'm using is unstable? How would I, the end user know there's a problem? Thanks Guys!

While I admit that maintaining two "similar" archives (lossy and lossless) can be a pain, I suggest you look into foobar2000 and the foo_dop plugin. It allows really nice integration with the iPods. It can even transcode your lossless files for you. I haven't tried this yet, but I actually think that it does it nicely, that is keeping your files/tags in sync without transcoding unless it needs to. Give it a try.

Personally I wouldn't care having lossless music with me on my iPhone even when it's 32GB. I'd rather have much more music with me that I can't hear is compressed anyway.

Foobar is a nice little program and I love those components. I installed the Bit Compare component and I compared an original Wav to a wav after transcoding to ALAC (with FFmpeg) and decoding it. Actually I compared every track in the album and there was no difference. I did the same with EAC using Wav compare but Foobar makes it easier. I'm very happy with that result. I read the original FFmpeg encoder was padding the last frame.

These Shure ear buds made all the difference. They were $250 but in all honesty, I prefer listening to my ipod now then my Harmon Kardon 7.1 receiver and Polk speaker set-up. I have a Creative Fatality card and I pipe it through the SPDIF. With the stock ipod ear buds it's really pointless to go lossless I think.

The only thing I don't like is I wish the ffmpeg encoder would add a md5 hash check like Flac does. When I finish encoding I just add an md5 manually to be on the safe side. I see no reason not to convert all my lossless to ALAC now and just keep one archive. I'll be able to free up about 1TB by removing my lossy mp3's too.

I'm not familiar with ABX. I'm not sure exactly what you're saying really. I'm just saying with the factory ear buds I can hear any difference between a 192 kb/s mp3 and ALAC. I managed to fill my 32gb Touch in about one day with Lossless so I am open to a Hybrid solution. There has to be a happy medium out there but that would leave me with maintaining two archives again. I would essentially be replacing my mp3's not the Flac. I was hoping to replace the flac and delete the mp3's.

There has to be a happy medium out there but that would leave me with maintaining two archives again. I would essentially be replacing my mp3's not the Flac. I was hoping to replace the flac and delete the mp3's.

That's why I recommended foo_dop. As I understand, this component will completely take care of the lossy encodings for the iPod, but you will not have a lossy collection alongside with your lossless collection - It only encodes the files when transferred to iPod. From there it will maintain tags by syncing and only encode tracks that are not present.

^^ What he said I think my first real ABX test was a HE-AACv2 encoding of some electronic music. I was tearing apart when I couldn't hear a 32kbit encode from the source (this is of course not possible with *any* track).

I understand why he wants to use Cuesheets - he wants to keep all the pre-gap / count down information - so that burnt CDs will be identical to the originals, not just in terms of audio data, but in terms of track position and track count-downs on a "real" CD player. Maybe he cares about Hidden Track One Audio too - maybe even CD-text (can Cuesheets do that properly?).

Can you get this right without Cuehseets?

I understand you've got to decade back to .wav from ALAC to use Cuesheets properly, but assuming you're willing to do this, that's a solution - is there another?

Regarding HTOA-tracks, I number them as "00". I don't see how pregap are ever handled on portables. They are optimized to playback a single-track - not optimized to play RedBook audio, so why not stick to the best compatible method? Who has ever used pregaps anyway? I think I've seen a few live CD's where talking between tracks were stored in pre-gap, but isn't that it? Still pre-gaps can (with some manual editing) be seperated into tracknumbers as well (01a, 01b, 02a, 02b etc).

I don't think it has a "use" on a portable - I think it has a "use" in being able to re-create the original CD, if needed.

This thread seems to have 18 responses telling the OP that he shouldn't be worried about that! Well, he says he is.

If you want a practical use, I'll give you a for-instance: some CDs put things that only make sense when listening to a CD as a whole in the pre-gap. So if you're listening to the whole CD, you include the pre-gap, while if you're making a compilation, you exclude it.

It seems daft to throw away this information, even if you have no immediate need for it. It might come in handy.

(My wife says this will be written on my gravestone! I didn't want to throw this away - it might come in handy!)

I understand why he wants to use Cuesheets - he wants to keep all the pre-gap / count down information - so that burnt CDs will be identical to the originals, not just in terms of audio data, but in terms of track position and track count-downs on a "real" CD player. Maybe he cares about Hidden Track One Audio too - maybe even CD-text (can Cuesheets do that properly?).

Can you get this right without Cuehseets?

I understand you've got to decade back to .wav from ALAC to use Cuesheets properly, but assuming you're willing to do this, that's a solution - is there another?

Cheers,David.

You are absolutely correct David, good call. As long as you have a CD-Text write capable burner, and as long as you have a proper Cue file with the gaps appended (non compliant) You can burn a range copy (I guess that's what you call it) with EAC and produce a near identical copy of the original CD. If you burn a CD this way, in theory you could rip it again with EAC and it would pass the Accurip test (As long as your write offset is configured correctly). Actually I know it will but it's not good to pollute the accurip database with CD-R rips.

I save the HTOA if there is any, as the first track. I found if I split the single APE/FLAC file into Flac tracks with Cue tools, it will automatically generate a proper Cue sheet for me. I can then transcode the flac tracks with DB Poweramp. Then I'll delete the flac tracks but I'll save the log/cue file. This way if I want to burn an audio CD to play on an actual CD player with a digital display and count down timer, all I have to do is decode the ALAC with Foobar and change the cue file extensions from flac -> wav. It's actually a fairly simple process.

Does anyone know why Burrn or EAC can't burn ALAC using a cue file? I totally understand I can burn a gapless audio CD with itunes, I'm just curious. Thanks for all the help, I'm using DB Poweramp now and I found an easy way to accomplish what I was looking to do. I came to the right place.

Just because ALAC is new and because an open source decoder has only recently been made. It's not widely used in the Burrrn and EAC userbase because it's a format rather peculiar to Apple iTunes and iPod, and even then only recently. FLAC appears to be the current leader in lossless outside of the Apple world. For the same reason Windows Media Audio Lossless format isn't widely supported outside of Microsoft Windows Media Player.

Also, with lossless you can always decode to WAV first or transcode losslessly to FLAC before burning.

Your best bet for doing this without bloat is a player application like foobar2000 that only needs an input plugin to decode these more "exotic" formats to enable its full range of functions to work on that file format, including, say, foo_burninate

I seem to be having issues with ALAC encoded with DB Poweramp. Every track fails the Foobar Foo_Verifier test, it says the track lengths are a mismatch. The newest Foo_Verifier will check Accurate rips data base. DB Poweramp encoded ALAC albums all come up "not a proper gapless album". Also when I do a Bit Compare test against the Flac files that were transcoded, they all come back bad! BTW, I'm using the Ref 13.3 version of DB with all the latest plug ins.

Conversely, when I use Cue Tools with the latest ffmpeg ALAC encoder, every track passes the Foo_Verifier test, the Bit Compare, and the Accurate Rip (within Foobar). Everyone keeps telling me that FFmpeg is NOT archive ready. I beg to differ. Even if 1/1000 tracks is bad, the other 999 pass Foobars tests where DB fails every time. itunes encoded ALAC pass all those Foobar tests too. I see no reason not to use ffmpeg with Cue Tools. I like it better anyway because it creates an accurate rip log and it copies over the EAC log to the new folder. It makes a cue sheet with .m4a extensions but they can always be edited to work with .wav down the road.

I would like to know why DB Poweramps ALAC encoder has so many problems with Foobar though.