You guys have sold me. I'm going to convert my FLACs to ALAC and then keep a lossy collection as well.
I thought I would already start tonight, but it turns out that XLD has a few settings for ALAC, so now I need to read up on what they're all about. (I'm pretty ignorant that way.) I'm kind of surprised that lossless has "settings". It would seem that there wouldn't be different quality levels of lossless, but XLD has settings for sample rate and bit depth, neither of which I know anything about with regards to ALAC. Also don't know anything about embedding cue sheets as a chapter during conversion.
I'm sure someone on this forum has already discussed these things. If they have, I'll find it and figure out what I'm doing.
Thank you for your help, everyone that replied.
You guys have sold me. I'm going to convert my FLACs to ALAC and then keep a lossy collection as well.
Good advice from "the guys". I'm sure the audio will be converted without loss.
It might be a good idea though to verify if all your (precious?) FLAC metadata transfer correctly to ALAC before you start to convert your whole collection.
First, you do
of course a backup? If not, then this is the right time to do one. Keep your FLACs as of now. At least until you know that everything went well.
Keep folder structure. (Import the FLACs as a playlist, import the ALACs as a playlist, use a bitcompare utility.) Your player may sort incoming so that this is not an issue, but unless you know what you are doing, keep everything as equal as possible.
I'm kind of surprised that lossless has "settings". It would seem that there wouldn't be different quality levels of lossless
- The audio signal will be identical, unless you set it to do conversion to e.g. a different sampling frequency (44.1 in should be 44.1 out) or number of bits per sample (if you have a 24 bit file and convert it to 16, you will not get the same out). Make sure you keep output as source.
- A lossless encoder will also have settings for how much CPU it should use to encode. Many .zip packers also have this. The encoder tries to find patterns it can exploit in order to pack the signal tighter, and that takes more CPU cycles and more time. You can very well set the encoder at a high compression rate if you have time to wait. Encoding is done once.
(I cannot give any help on settings on appleware, but others likely can.)
Holy smokes. I am really humbled by all the attentive help on this forum. Thank you VERY much, all of you who responded.
It might be a good idea though to verify if all your (precious?) FLAC metadata transfer correctly to ALAC before you start to convert your whole collection.
Yes, very precious. I have many FLACs of important classical and jazz albums that are no longer in print. If something went wrong, I would have a difficult, if not impossible, time replacing these files. Yes, I also do keep a backup on a separate drive.
Very good suggestion about verifying the conversion, of course. I read that XLD has the ability to "confirm" rips from CD, although I have not yet learned how to do that. Does anyone know if XLD can confirm if a transcode worked properly from FLAC to ALAC ... or is there some other way of confirming this?
Also very important to me, is the ability to confirm that all the gapless information was handled properly. The last time I tried to convert any media was perhaps ten years ago using iTunes to rip my CDs to compressed files. iTunes at the time did not yet have it's gapless technology together and the gaps were messed up. I was so traumatized by the incident, I haven't transcoded anything since! (And the only reason I'm willing to try again now is because so many people on this forum speak so highly of XLD.)
So would I be able to verify the data, including the gapless/pregap info, from FLAC/APE to ALAC using XLD? That would REALLY be some comforting assurance, since I obviously can't listen to hundreds of albums just to make sure they made the switch properly.
That would allow me to make the dream a reality ... transcode all the FLACs/APEs to ALAC, backup the new iTunes-friendly files to the second drive, and in the process delete the FLACs entirely. I would have to be VERY confident in the software and the transcoding verification to do that, though.
There is no need to be concerned about gapless playback when converting from flac to alac. Lossless is lossless!
There is no need to be concerned about gapless playback when converting from flac to alac. Lossless is lossless!
Thanks, greynol. Just so I'm sure of what you're saying ... whether I have multiple-track FLACs with a CUE, or one album flac with a CUE, or multiple-track FLACs without a CUE ... there is no setting in XLD I can accidentally leave ticked on or off or with a wrong value set (etc) that would cause me to mess up the gaps? That problem I had with iTunes screwing up my gaps ten years ago no longer exists?
This is the one issue that caused me to give up on encoding my CDs ten years ago and freaked me out on the idea of trusting conversion software ever since, so please forgive the persistent questions.
The problem with gapped playback has to do with lossy encoding.
Also, gapped playback really has nothing to do with cue sheets, other than people have used them to index a mp3 created from a wave file of the entire CD.
The word gaps might be the same but their meaning is completely different.
That would allow me to make the dream a reality ... transcode all the FLACs/APEs to ALAC, backup the new iTunes-friendly files
If you have access to a Windows computer, then you would easily get help doing both copying (directory structure preserved, and with additional files like .log and .jpeg moved) and verification with foobar2000.
Do however make sure that tags - including embedded album art! - are transferred correctly. FLAC allows arbitrary tag names, I don't know if ALAC does. As for album art: be sure to test one album with multiple pictures embedded (if you have any such).
... gapped playback really has nothing to do with cue sheets, other than people have used them to index a mp3 created from a wave file of the entire CD.
The word gaps might be the same but their meaning is completely different.
Well, now you completely lost me, greynol. My (limited) understanding is that the gaps between songs is either an actual break between the files, determined by the player, or in the case of gapless, the transition between files is seamless, but the moment of silence is actually a part of the song. And the problem in transcoding is when the exact length of the gap/gapless is not carried over and the transcode reverts to some default amount of time, resulting in an wanted gap in, say, a continuous live album.
And my limited understanding of cue sheets holding gap data simply comes from me dropping the small cue sheet file onto the XLD icon and up pops the whole album in the transcode window with pregap values already filled in.
But again, that's just a bunch of heartache talking that came out of trying to transcode my large CD collection ten years ago when iTunes was notoriously inept at handling gaps perfectly. (I continuously got live albums with brief gaps between songs.) It's also my only last concern about transcoding FLACs to ALAC, since XLD does seem pretty straightforward with regard to settings. There's not too much there for me to learn or screw up. It'll either do it right or it won't.
I have no idea what you mean by "the word gaps might be the same but their meaning is completely different". Maybe it's not important for me to know. If you say that gaps are no longer an issue with XLD, as they were with iTunes, then I can leave it at that.
If you have access to a Windows computer, then you would easily get help doing both copying (directory structure preserved, and with additional files like .log and .jpeg moved) and verification with foobar2000.
Do however make sure that tags - including embedded album art! - are transferred correctly. FLAC allows arbitrary tag names, I don't know if ALAC does. As for album art: be sure to test one album with multiple pictures embedded (if you have any such).
Sadly, I do not. I have a brand new iMac with XLD, but no PCs around. What you're saying though is exactly what I want ... just the ability to transcode to ALAC and then use some reliable verification system, so I'm not doing some silly thing like actually listening to album after album to see if they transcoded properly with the correct song gaps. That doesn't work when we're talking hundreds and hundreds (and hundreds) of FLACs.
I read good things about XLD as a transcoder, and I've read where people refer to "secure ripping", (which I assume applies only to transcoding from actual CDs), but I haven't read about any such feature that will let me confirm the transcode from FLAC to ALAC.
It's starting to sound like I'm going to have to keep all my original FLACs (plus their backups, that's two separate drives) in addition to the new ALACs (plus their backups, again on a separate drive) so that if an ALAC is found to be bad, I can go back to the original FLAC to do it over properly.
I sure wish there was some Mac alternative to this Foobar2000 software you're talking about. Transcode to ALAC and verify the lossless file. How hard should that be to get on a Mac?
The audio data on the disc either contains silent sections at track transitions or it doesn't. How these transitions are indexed is not relevant unless you tell your ripping or image splitting program to do something non-standard. The standard way of ripping to PCM as one track per file (and any compressed lossless format) will keep these transitions exactly as they are on the disc unless the ripping program is broken or somehow configured to do something non-standard (intentionally or otherwise). If you convert from one lossless format to another the audio data remains the same, otherwise it isn't lossless. If the audio data remains the same and the transitions are in the audio data then the track transitions will also remain the same. EDIT: The same is true when ripping an entire album to a single file.
In the previous paragraph I mentioned transitions being indexed. This is information in the sub-channel data, not the audio data. This sub-channel information is stored in the cue sheet if it was detected by the ripping program. If you want to see the contents of a cue sheet, open it up with a text editor. On an audio compact disc, gaps, pregaps, pre-gaps, 00 indices, 00 indexes, whatever you want to call it, are just areas in the audio that are labeled in the sub-channel data. These areas may be digitally silent, may contain low-level noise, may contain signal, or any combination.
These areas indexed in the sub-channel are not the same thing as whether your software or hardware media player is able to properly transition from the last sample of the previous file to the first sample of the current file. Whether this transition when changing files can be done correctly with a lossy format depends on the capability of the encoder and whether it plays nicely with a player that is capable of gapless playback. Whether this can be done correctly with a lossless format only depends on the capability of the player. It has nothing to do with the encoder because the encoder is lossless.
Lossless is lossless is lossless is lossless. If it isn't lossless then something is broken.
Exceptional explanation, greynol. Thank you. That post should become an FAQ answer, if anyone else were asking this question.
Can you give me any insight into the question in the second half of my post? Pregaps and confirming my transcodes are really my only two concerns since resolving to use ALAC. Since you've assured me that any gap issues I experience would only be as a result of the source file or playback software, that's no longer an issue.
Do you have a suggestion for what to do (or where to learn) about confirming the FLAC to ALAC conversion? Again, I'm on a Mac using XLD.
Other than possibly to change the file name and file type in the cue sheet, the rest of the information should stay the same so pregaps should not be an issue.
I'm strictly a Windows guy so I can't help you with verifying the integrity of lossless conversion on a Mac. A simple, efficient and effective way to do this is to:
1) convert flac to alac
2) decode alac to raw pcm
3) find the md5 hash of the pcm
4) compare this hash with that stored in the flac file
About cue sheets, their true intended purpose is to help create a more perfect replica of the disc when burning to CD-R/RW. The use of cue sheets has evolved, though aside from indicating whether a disc has pre-emphasis, they are not necessary if your tracks are stored as individual files and you don't intend to burn copies. The limited metadata they contain should already be present in the files themselves, with the possible exception of ISRC/UPC data which is of questionable value.
Of course if you are ripping to single-file images, CUE sheets are indispensable; though converting a single-file image form one lossless format to another will still not cause or necessitate a change in the sub-channel data found in the cue sheet.
Thanks, greynol. That sounds easy after I've done it a few times. Looks right now like a bunch of steps to repeat for each of the hundreds of FLACs I'll be converting.
Let me please put the question out there for the Mac-savvy members ...
... is anyone confirming their FLAC/APE to ALAC conversions? How are you doing it?
Or is there even a reason to? Perhaps XLD executes the conversions with such perfect reliability that a confirmation is not even necessary?
-J
Looks right now like a bunch of steps to repeat for each of the hundreds of FLACs I'll be converting.
It is possible to run command lines on appleware ...
What you would want, is something that looks for every
X:\<path>\<filename>.FLAC
looks up
Y:\<same path>\<same filename>.ALAC
and compares them, and yells if it doesn't find the file or if it does not match. Re greynol's suggestion: AFAIK, there is no checksum in ALAC, so it has to be decoded and md5sum generated. (You could convert back to FLAC and use metaflac on both, but ...)
I did a search for audio comparing software under OS X. Found one hit on this forum, that is 10 years old ... http://www.hydrogenaudio.org/forums/index....showtopic=21267 (http://www.hydrogenaudio.org/forums/index.php?showtopic=21267)
Looks right now like a bunch of steps to repeat for each of the hundreds of FLACs I'll be converting.
Let me please put the question out there for the Mac-savvy members ...
This thread title might not attract the right answers.
Sure you cannot borrow someone's Windows computer for a night?
... is anyone confirming their FLAC/APE to ALAC conversions? How are you doing it?
Do you know xACT (http://xact.scottcbrown.org/)? It's a great utility for Mac. I haven't used it to convert to ALAC, but it's versatile and the developer is very responsive. XLD and xACT have overlapping features, but it's great to have them both. xACT has checksum features, so it might do the trick for you.
Do you know xACT? It's a great utility for Mac. I haven't used it to convert to ALAC, but it's versatile and the developer is very responsive. XLD and xACT have overlapping features, but it's great to have them both. xACT has checksum features, so it might do the trick for you.
Thanks for the suggestion Kees. I've never opened xACT because I read that XLD is easier to use ... and I have a vague memory of someone saying that xACT doesn't do ALAC. But that's just a fuzzy memory from reading too many google results on the question. I'll read up on xACT right away. Even if it's much more difficult to use than XLD, just the ability to confirm conversions is worth the hassle. If a guy is going to convert an entire collection - and especially if he wants to erase the source files afterwards - confirming the transcode is mandatory.
Either that or I suck it up and buy two more hard drives (one for ALAC collection, another for backup) so that my FLACs remain in the house if something goes wrong. That's a lot of extra $$, but this is an important (to me) music collection we're talking about.
So what you have is single-file per album with cue-sheets embedded flacs now?
If yes, then is there a sample like that online? (I can probably bash something up, if it's not too hard).
So what you have is single-file per album with cue-sheets embedded flacs now?
I have single file FLACs with CUE, multi-track FLACs with CUE, as well as APE with CUE. I don't know what 'embedded' means. The CUEs are always a separate file in the album folder.
Then they aren't embedded, unless they somehow managed to find their way into a tag as well.
PS: I edited my earlier posts to include the case of single-file images. The only reason was to reassure you that the conversion process will still not affect the sub-channel information in a cue sheet.
So basically cue-sheets stay as they were or do we want splitted tracks (based on this cue-sheets)?
edit: actually forget that, you have tools online (google) that will split flac to flacs, based on cue sheet. I'll try to do some work on audio verification (verifiying decoded alac vs decoded flac, based on md5sum) and will not deal with cue-sheets at all.
ok, so this will take only files as input currently (and only with .flac extension), what it does;
a. Uses ffmpeg to convert to ALAC
b. calculates FLAC raw audio crc
c. calculates ALAC raw audio crc
d. compares b. and c., says ok, or says error
Relevant part of sh looks like;
for files in "$@" ;do
# check if it is a file
if [[ -f $files ]]; then
echo "$files"
if [[ $files == *.flac ]]; then
out="$files"
# ffmpeg command:
./ffmpeg -loglevel warning -i "$files" -acodec alac -vn "$out.m4a"
# echo "original md5"
origcrc=$(./ffmpeg -loglevel warning -i "$files" -f crc -)
# echo "alac md5"
alaccrc=$(./ffmpeg -loglevel warning -i "$out.m4a" -f crc -)
if [ "$origcrc" == "$alaccrc" ]
then
echo "crc ok" "$origcrc"
else
echo "crc error"
say "crc error"
fi
else
echo "not a flac extension"
fi
else
echo "not a file"
fi
done
download (it's a droplet);
https://dl.dropboxusercontent.com/u/7953236...ToALACcheck.zip (https://dl.dropboxusercontent.com/u/79532365/tmp/audioToALACcheck.zip)
(only slightly tested and only on Mavericks, should work on Mountain Lion as well thought ...)
There's no need to calculate the hash for the flac, it's already stored in the file.
metaflac --show-md5sum
I guess the OP has some Monkey's Audio to deal with as well.
@greynol
a. The app could be easily extended to take any FFMPEG supported audio input
b. FFMPEG has a built in crc calc format, so md5 is not that usefull
Why waste cycles decoding a flac file in order to get information that is already stored in it?
Perhaps I don't understand what your script is actually doing.
Here's a portion of my code as an example of how I verified a flac conversion to tak 2.2.0 in a windows batch file:
:encode_from_flac
flac.exe -dcs %1 | takc.exe -e -p0 -ihs -sts3 - "%~dpn1.tak"
IF %errorlevel% NEQ 0 GOTO error
FOR /F "usebackq" %%X IN (`metaflac.exe --show-md5sum %1`) DO SET md5flac=%%X
FOR /F "usebackq" %%X IN (`takc.exe -d "%~dpn1.tak" - ^| sox.exe -t wav - -t raw - ^| md5sum.exe`) DO SET md5tak=%%X
IF %md5flac% NEQ %md5tak% ECHO Fail && GOTO error
GOTO :eof
Like i said, the input could be more than just FLAC in the near future, also ALAC doesn't seem to carry md5sum info and we have native crc format allready provided inside the FFMPEG. Perhaps I'am not sure what part you don't understand.
I'm just thinking about efficiency and something that is least susceptible to corruption. The flac is only decoded once in order to convert to alac.
The alac is decoded once to generate a checksum. The pcm checksum from the alac encode is compared against the checksum stored in the flac that was created from an entirely different process (when the flac was originally created).
If one can't easily generate an md5 hash of pcm decoded from alac then it's moot, though I find that hard to believe.
IOW, maybe ffmpeg isn't the best tool for the job, but then again, maybe it is if you use a Mac.
Your example uses 4 tools to do only a flac2tak conversion, when mine uses a single tool for any possible future multiformat lossless conversion, so what is wrong with ffmpeg? (And mac can run a real shell script natively, not that windows bat mess).
The pcm checksum from the alac encode is compared against the checksum stored in the flac that was created from an entirely different process (when the flac was originally created).
Right, that could be a valid one.
If it isn't valid then the integrity of the new alac file is the last thing you need to worry about.
Except to ask you how many times is ffmpeg decodes the flac file, I'm really not interested in escalating this into a pissing contest. Note that I wasn't the one who referred to your code as a mess.
Except to ask you how many times is ffmpeg decodes the flac file
This could be done in single decoding pass (I'd have to read the ffmpeg man for that a bit), right now it does it two times.
It is safest to compare to a checksum generated from a separate pass on data that isn't cached, so why not use the one stored in the file?
I shouldn't have taken your "bat mess" comment personally, I think you were just insulting Windows.
Right, lets see if John 31415926 (and possibly other rare OSX users) can make a use of this tool, before any unnecessary complicated future development.
edit: Quick benchmark: Random album (60 min) is transcoded/crc checked in 42 seconds.
I'm probably just being paranoid, though I've fallen victim to a bad stick memory in the past.
FWIW, those pieces of code in my bat that do verification are commented out, but I rely on other methods of verification such as CUETools when appropriate.
A few possible catches:
(1) It could be a good idea to check the integrity of the FLAC files in the process yes; does ffmpeg output an error if trying to convert from a FLAC that fails to match its md5sum?
(Of course, one could just take whatever file-pair might in the end turn out suspicious, and do that check to see what the explanation is.)
(2) Does ffmpeg transfer absolutely all tags?
-> are all Vorbis comments transferable to ALAC, and what will ffmpeg do if it encounters ones that are not?
(3) Does ffmpeg split by cuesheet? Does the OP want single-file-plus-cuesheets to be split? (Does iTunes support single-ALAC-plus-cuesheet?) Does ffmpeg generate external cuesheet with the correct references? Does it handle all non-compliances?
(4) Write a log file with the appropriate level of information (several lines per file to tell it is OK is likely not too readable ...)
@Porcus
1. No idea, but I can code in metaflac md5sum check as first operation, that is if metaflac is found installed on the system (I can't seem to google out static flac binary).
FFMPEG also has an md5 format (dunno how i didn't see that yesterday), so if the input file is 16bit then the direct check with ffmpeg results is possible, however this will fail with files other than 16 bit, due to ffmpeg internal conversion to raw 16 bit format before md5 calculus (Haven't actually tested this yet).
2. No idea, seems like all the text tags are there in this new ALACs.
3. I will not bother with cue-sheets at all, I will not bother with itunes at all, ect.
4. yes to logging, but no promisses of being nice to look at, maybe like this:
ok /path/to/orig1.flac
ok, differs from stored md5 /path/to/orig2.flac
error /path/to/orig3.flac
ok /path/to/orig.ape
that is if metaflac is found installed on the system (I can't seem to google out static flac binary)
You mean, a metaflac binary for OS X? It seems to be part of http://sourceforge.net/projects/flac/files...win-ppc%2Bi386/ (http://sourceforge.net/projects/flac/files/flac-darwin/flac-1.2.1-darwin-ppc%2Bi386/) .
version 2
https://dl.dropboxusercontent.com/u/7953236...ALACcheckV2.zip (https://dl.dropboxusercontent.com/u/79532365/tmp/audioToALACcheckV2.zip)
changelog;
- does single pass for transcoding and md5 calculation
- will correctly handle highbit flac sources
- enabled APE extension as input (not tested, but should work)
- if you re-drop the files again (and ouput alac files are in place) it should just re-check original vs alac.
- droplet has pretty icon
- simple logging (md5log.txt), example;
OK 3c0fc518b39a2ee434ac08f1620489b3 20. Janis Joplin - Come Back
OK fc9d7e905d7c9ed6d7de11396d82ce99 19. Janis Joplin - My Own Tears
OK 378474cfd769756a0e50ac484f501de4 18. Janis Joplin - Time
OK 19d93fa397521f06f2036604259cb1bb 17. Janis Joplin - Little Girl Blues
OK 919ef04f5ee86f86bf3cb76587e3e21f 16. Janis Joplin - Get It While You Can
OK ce617e1c71e84ffff048ea5690cbe6ed 15. Janis Joplin - Trust Me
Shell script is embedded and can be edited (or stolen) directly in place.
(./audioToALACcheckV2.app/Contents/Resources/script)
p.s. Same script should run on linux if you fix the paths to ffmpeg and disable that "shift" at the beginning.
p.s.2. metaflac idea temporarily forgotten, droplet still takes only files as input (no dirs).
Hi smok3,
You're doing all this generous work on my behalf, but you're so far above my league, it would take me days or weeks to be able to implement what you're doing. I know nothing about scripts, command lines, and all the encode terminology you're using. I'm at the point where I'm very pleased to have figured out how to set iTunes to encode a CD to AAC. I'm getting the hang of using XLD, although I still use some of the parameters without understanding what they are ... I just found them recommended somewhere by someone who sounded knowledgeable. Still don't know what CUE sheets do, although I know to drop them onto the XLD icon to get the ball rolling. That's about as far as I've gone with these things.
My next step is to look at xACT ... Kees de Visser, one of the posters on this thread, said that it does ALAC and also confirm transcodes.
I'd love to do something with what you're doing here as it sounds like you're creating something that addresses all my concerns, but you're obviously not a beginner and way ahead of me in my simple understanding of these things.
Have you viewed the contents of a cue sheet in a text editor as I suggested?
Have you checked our wiki?
http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet (http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet)
Thanks for that FAQ page on cue sheets, greynol. Very helpful. Having just read it, I guess I do know what cue sheets are - since I can see the effect they have when I drop a cue file onto XLD. A single FLAC file is suddenly broken up into songs with all titles, pregaps, etc ready to go. I thought there was more to CUEs than that, but they're really pretty straightforward. Thx again.
I'd love to do something with what you're doing here as it sounds like you're creating something that addresses all my concerns, but you're obviously not a beginner and way ahead of me in my simple understanding of these things.
I'am just trying to address the conversion of files with md5 check, specifically ape and flac to alac. As for cue-sheets, one could use another tool to do the splicing before my little dropplet (so I'am completely ignoring them).
It was an interesting learning experience and I found some really nasty default ffmpeg behaviour (with highbit depth stuff) and a way to workaround it.
You're doing all this generous work on my behalf
Nah, that all goes to my personal glory and I think I anger greynol a bit as well, so that's a plus as well.
Well, I was excited about the suggestion for using xAct for Mac to convert FLAC to ALAC with an extra step to confirm the transcode, but it's a no-go. I downloaded the software and went through it, but xAct doesn't convert to ALAC. The best it can do is convert to WAV or AIFF and then iTunes can convert that to ALAC. That much I already had in XLD.
So, right now it seems I have the choice of either using XLD and having no confirmation that the transcodes are identical (ie, no errors were introduced during the lossless transcode) ... or buckling down and seeing if I can make sense of smok3's process that he came up with. I have no idea if his steps are easy or hard ... I have never used command lines (don't know what they are) nor do I understand most of the terminology he uses. I'm a pretty basic computer user.
Seems strange to me that converting FLAC to ALAC with a desire to confirm the transcode is not more common among Mac users. I read about guys doing this conversion everywhere, but everyone seems to feel completely safe immediately deleting their FLACs, simply going on faith that their transcodes came out perfectly. Hardly a mention anywhere on google about confirming lossless transcodes.
Maybe I'm just being paranoid? XLD doesn't make errors ... ever?
Would love to try Foobar2000, but, like I wrote, I have no access to a Windows computer for a project of this scale.
...I downloaded the software and went through it, but xAct doesn't convert to ALAC. The best it can do is convert to WAV or AIFF and then iTunes can convert that to ALAC...
It actually does. Bottom-right corner under the Encode tab. Please note that Apple Lossless and ALAC are one and the same.
...I downloaded the software and went through it, but xAct doesn't convert to ALAC. The best it can do is convert to WAV or AIFF and then iTunes can convert that to ALAC...
It actually does. Bottom-right corner under the Encode tab. Please note that Apple Lossless and ALAC are one and the same.
Thank you for replying, Engelsstaub.
Doop. There it is. I was looking at the decode screen and missed the ALAC option on the encode screen. That, plus I video-googled FLAC to ALAC via xACT and some fellow had put up a video showing how he used xACT to encode to WAV, then to iTunes, then to ALAC. He's either in the dark (like I was until just now) or the video comes from an old version of xACT that didn't yet have ALAC.
Engelstaub, as long as I have you already helping me ... once I've converted from FLAC to ALAC, can you tell me the steps in xACT to compare the two lossless files so I know no errors were introduced during transcoding? Or do you know where a tutorial can be found? (I've looked and found no instructions for this.) I could probably figure it out with a couple of hours of trial and error, but if you know how to do it, I would greatly appreciate some experienced help.
once I've converted from FLAC to ALAC, can you tell me the steps in xACT to compare the two lossless files so I know no errors were introduced during transcoding?
Are you overclocking your PC and worry that it will make computational errors? If not then don't bother comparing the lossless files. Their audio content will be identical.
once I've converted from FLAC to ALAC, can you tell me the steps in xACT to compare the two lossless files so I know no errors were introduced during transcoding?
Are you overclocking your PC and worry that it will make computational errors? If not then don't bother comparing the lossless files. Their audio content will be identical.
I don't think I'm doing anything unusual with my Mac, so overclocking is not a concern.
I read the following post on this forum:
http://www.hydrogenaudio.org/forums//lofiv...%20/t67377.html (http://www.hydrogenaudio.org/forums//lofiversion/index.php/t19129.html%3Cbr%20/t67377.html)
If you don't care to read the whole thread, the main portion that I latched onto was:
"I am converting the FLAC files in my music collection to Apple Lossless. Is there any reason why I should keep a copy of the original FLAC files? I couldn't imagine any reason why I should, since no actual data is being lost during the conversion, but maybe there is an element to this I am missing?"
"No, there isn't any reason to keep the original FLAC files. Just make sure that your conversion software verifies your Apple lossless (ALAC) files. There are some errors that can be introduced during the encoding process due to processor load and other issues. These errors are rare but they can happen. That is why you want software that will check the CRC values. It will look at the CRC values of the FLAC files and compare them with the CRC values of the ALAC files. Everything is fine if they all match up."
---
I've gotten as far as learning that xACT does exactly that ... so I'm still hoping someone can give me the steps to do this comparison process so I don't have to learn it from scratch.
So, still looking to compare original FLACs and newly created ALAC files before I delete my originals.
I would rank the importance of checking that files have been en/decoded correctly very low compared to the importance of keeping two separate copies of the files. If you wanted to keep both the original FLAC and the transcoded ALAC (on separate media and preferably in separate locations) then that would serve the backup function.
Thanks, pdq. I have no interest in keeping the FLACs.
What I want is to convert FLAC to ALAC, confirm the ALAC is a perfect match, back the ALAC up to a separate drive, then delete the original FLAC. I have an enormous number of albums and no interest in buying yet another hard drive (or two) to keep both formats. (We'd now be up to drive space for original FLACs, drive space for copy ALACs, and drive space for lossy AACs.) For now, if I can just get everything to ALAC and nothing else, I would be able to use iTunes for playback and not have to fuss with alternate file formats or non-iTunes players any longer.
Apparently confirming a newly created ALAC can be done in xACT. (I'm told it's routinely done in Foobar2000 by Windows users.) I just want to learn how to use this feature. If anyone can help, super. I would really appreciate it. If not, I'll learn what CRCs, MD5s, and checksums are and start rooting around xACT and see if I can figure it out.
If it's just too time-consuming, I'll give up and save the FLACs as backup. But I prefer to verify the transcoded ALACs and delete the FLACs entirely.
Fingers crossed that someone has done this and can pass the steps along to me.
...Engelstaub, as long as I have you already helping me ... once I've converted from FLAC to ALAC, can you tell me the steps in xACT to compare the two lossless files so I know no errors were introduced during transcoding? Or do you know where a tutorial can be found? (I've looked and found no instructions for this.) I could probably figure it out with a couple of hours of trial and error, but if you know how to do it, I would greatly appreciate some experienced help.
I actually don't use any verification methods other than use of the AccurateRip database if I'm concerned. (This can be done with your ALAC files even without a cue sheet by using "Open Folder as Disc.")
Never been that concerned about it and have never observed errors IME when transcoding from lossless-to-lossless. I could be mistaken but I'm almost certain xACT or XLD won't decode or encode through errors and would report them when the process is completed.
Really the AR database is the best way to verify any securely-ripped CDs IMO. If you have lossless stuff from web sources like Bandcamp, HDtracks, Qobuz, or other (questionable) places that weren't accurately ripped then it's a bit pointless (again IMO) to worry about bit-for-bit accuracy or whatever. I personally wouldn't. Either the files will play or they won't.
Sorry I can't be more helpful than that.
Thanks, Englesstaub.
From what little I've learned, it sounds like this idea of confirming ALACs made from FLACs is no minor project. In my mind, I was picturing something like burning a DVD with Toast. After Toast burns a DVD it automatically does a comparison between the newly burned disc and the source file and tells you afterward "DVD burn successful". It doesn't seem like it's that straightforward with comparing the FLACs to ALACs. Time consuming extra steps could make converting hundreds upon hundreds of FLACs unfeasible.
Might just have to go on faith, transcode my files, and hope for what you've experienced ... no errors when transcoding lossless-to-lossless. I guess the few problematic files I might run into (or however many) will be a small price to pay for just getting this finished and getting on with enjoying my music.
Thanks again.
For cd's I own that were accurately ripped using EAC I always add a bmp picture with filename, filesize and CRC32.
example:
(http://oi58.tinypic.com/212v5lk.jpg)
This gives me the possibility to check at a later time, even after transcodes to other lossless formats, if a decode to wav is still bitperfect / accurate.
I create these images with WinRAR (to calculate the CRC32 checksum) printscreen and Paint.
The main thing he is saying he needs is a program that will run on Mac OS and that will show him the MD5 checksums ("fingerprints" they are sometimes called) that the encoders embedded in his FLAC and ALAC files, so he can compare them to make sure they are the same. Or something that will compute new checksums and compare them for him.
Telling him about WinRAR, BMPs, Paint and CRC32 checksums that he has to somehow obtain is not going to fly. He needs a step-by-step guide with as few steps as possible. Surely someone out there has some Mac software to recommend?
Thanks MJB. Good to know somebody understands and is watching my back here.
I'm starting to think I've asked for too much ... at least for Mac OS. Windows seems to have ready solutions. I starting to think I should lower my standards and just settle for encodes without verification and let the chips fall where they may ... or take pdq's expensive advice and keep all my FLACs in addition to my ALACs in addition to lossy portable files. Ouch, but I don't see any options as of this moment. Still waiting though for prince charming to ride in and slap down a step by step process on software that's fairly easy to work with.
For what it's worth, here is as far as I've gotten with xACT. The encode screen looks pretty straightforward. I assume I just pick my desired outcome format, drop my FLACs onto the window, and click encode.
It's the checksum screen that could use a tutorial. (How can there be software in this world without a tutorial?) Does this screen look like it's made to have two lossless albums analyzed for similarity? It seems as though it's just for analyzing the original file against its own MD5 ... if I understand the concept right. An MD5 is a short summary of an album that would tell me if I'm missing sectors or have errors? I see where I can compare a file to its MD5, but not for comparing two distinct folders of music.
I don't see anything that looks like a place for putting in two folders and clicking "compare".
(http://farm8.staticflickr.com/7302/12965356944_2b835b1528_o.png)
(http://farm8.staticflickr.com/7404/12965076553_99f0c30742_o.png)
Actually ... there is https://github.com/xeoron/foobar2000-mac (https://github.com/xeoron/foobar2000-mac) too. Can you get Wine and fb2k working? Then you will have lots of help at hydrogenaudio :-)
I do not know whether ALAC is checksummed. If it is, then a tool to check integrity should likely substitute for bitcomparing. But I would never trust a conversion without verification - I've had disk writes failing and that sort of stuff, unrelated to overclocking, and I have had to resort to ancient backups on a couple of occations. Windows though ...
(I would not use a non-checksummed lossless format at all, at least not without checksum files ... which I hope checksum the audio only.)
Thanks for that link, Porcus. I have never experienced Wine (don't even know what you're referring to there) and FB2K (have heard of that) before, so I don't know what you mean by getting them "working".
I will install FB2K this weekend and see what I come up with.
This might be my last shot at getting verified ALACs. If I can't make this work by this weekend, I'll probably just buy yet another two drives, make my ALACs, back them up, and still save the original FLACs - and their backups. Not to mention a stash of portable lossies. (Sheesh. Getting ridiculous here.)
All this just to have ALAC at home and AAC on the road.
I seem to be investing a lot of time into something no other Mac people are doing, so the added drives are starting to look less expensive than the too many hours I'm investing learning something that just doesn't seem to want to happen.
Still, I'm going to open FB2K this weekend and see what's going on there.
-John
ps. Does anyone know anything about Porcus' question about whether ALAC is checksummed? I don't understand much about this, but I'm assuming that if it's not, then there is no way to compare it to another lossless file without time consuming extra steps. (?)
Thanks for that link, Porcus. I have never experienced Wine (don't even know what you're referring to there) and FB2K (have heard of that) before, so I don't know what you mean by getting them "working".
Wine is a compatibility layer to run Windows applications on unix-alike operating systems. Might not be easy, as it isn't fully supported: http://wiki.winehq.org/MacOSX (http://wiki.winehq.org/MacOSX)
dbPoweramp has option to verify conversion to ALAC. But for now it is only Windows application. However, I see that there are planes to port dbPoweramp to MacOS (http://forum.dbpoweramp.com/showthread.php?31308-dBpoweramp-for-Apple-Mac). You can contact Spoon (developer of dbPoweramp) and ask him about this project. If it happens soon, it might be good idea to wait a month or two for this software.
dbPoweramp has option to verify conversion to ALAC. But for now it is only Windows application. However, I see that there are planes to port dbPoweramp to MacOS (http://forum.dbpoweramp.com/showthread.php?31308-dBpoweramp-for-Apple-Mac). You can contact Spoon (developer of dbPoweramp) and ask him about this project. If it happens soon, it might be good idea to wait a month or two for this software.
dBpoweramp is definitely an application that may be handy for the less tech-savvy yes.
Agreed. dBpoweramp would definitely be worth the wait. I just posted the question on their forum. Thanks, detmek.
http://forum.dbpoweramp.com/showthread.php...3862#post143862 (http://forum.dbpoweramp.com/showthread.php?33371-When-will-dBpoweramp-for-Mac-be-ready-to-use&p=143862#post143862)
---
Asking those of you that use dBpoweramp on Windows ... this ability to confirm the transcode of one lossless format to another ... is it easy and quick to do? (I'm not talking about secure-ripping a CD. I'm talking about transcoding from FLAC to ALAC.) Is it as easy as the experience I have with burning DVDs on Toast where you just click 'burn' and it takes the file off the hard drive, burns the DVD, then rereads the new DVD and compares it to the original file for errors ... without me having to do or understand anything?
Or does confirming a transcode on dBpoweramp require a number of extra steps that involve an understanding of more new terminology?
I'm asking because I assume dBpoweramp for Mac would work the same way as the Windows version.
-J
As easy as this on Windows:
(http://fotkica.com/thumbs3/1_tmb_63375926_dBpoweramp%20ALAC%20verification.png) (http://fotkica.com/slike.php?slika=1_63375926_dBpoweramp%20ALAC%20verification.png)
Just a simple checkbox when you select destination format and location for new files.
@Porcus Yes, very easy to use. Although I use foobar for my conversions.
John; and dropping files to an icon was to hard or it didn't really work for you for some reason? (Just wondering really)
Detmek ... that screenshot pretty much ends the conversation. That's everything and exactly what I'm looking for. Now I wish to heck I had a Windows computer within reach so I could do this thing. But, supposedly the beta of dBpoweramp for Mac is due very shortly.
I also noticed on the same screenshot the ability to very easily generate a new folder from the artist and album title tags. Very very cool.
Thanks for posting that. VERY helpful and authoritative. No more questions from my end. None. Must ... own ... dBpoweramp.
Smok3 ... I really appreciate the effort you put forth to get me up to speed, but I think I was lost in a lot of terminology that I didn't understand. It's one of those things where I read one or two words or acronyms I'm not familiar with (and which don't google easily) and all the good stuff immediately after, regardless of how easy, is lost on me. I suspect that if I spent another couple of weeks with this stuff, then I would know not to get confused at some terminology you used - and more importantly, I could use your help and get my outcomes. Please don't be offended and give me a little longer to understand what I'm doing with this stuff, please.
ps. You can see the graphic on detmek's last post ... that's about the level of understanding I'm at. "Click here to automatically verify the transcode." That, I understand.
Interesting comment the author of dBpoweramp made on my question about when the software will be available for Mac.
http://forum.dbpoweramp.com/showthread.php...3862#post143862 (http://forum.dbpoweramp.com/showthread.php?33371-When-will-dBpoweramp-for-Mac-be-ready-to-use&p=143862#post143862)
He wrote, "There are no errors from FLAC to ALAC, never once in 10 years has a single error been found (there must have been 10's if not 100's of millions of conversions done in that time), that checkbox is there for piece of mind."
I understand that errors are rare, but my desire to verify my conversions came about because I've read posts on hydrogenaudio, even here in this thread, about verifying encodes because errors do in fact occur.
To say errors NEVER occur - that not even one has ever occurred - seems a bit of a stretch, doesn't it?
I don't claim to understand that much of how lossless codecs work, but this has never concerned me at all. I've been of the impression that XLD would crap out an error message if the conversion wasn't error-free.
IMO you should really just keep your FLAC and APE files, transcoding them to ALAC for iTunes per album/as needed, until you feel more confident in lossless-to-lossless conversions. (I mean, if dBpA for Mac is right around the corner with its checkbox then I don't think it's too big of a deal to put your whole batch-conversion plans off for a bit until you find all the answers you need.) FWIW I have a Mac and rarely use Windows for anything anymore. Still I rip CDs to FLAC for archival purposes and generate AAC or ALAC files for my iTunes library as needed from those.
I've had issues, but they have not been related to the conversion itself but to writing to disk. When I leave the thing unattended for a couple of days with an application that does not write a detailed (grep'able) log file, then I verify afterwards.
Also I've had every sort of user error, of course
Re the checksum issue: http://www.hydrogenaudio.org/forums/index....showtopic=65895 (http://www.hydrogenaudio.org/forums/index.php?showtopic=65895)
I mean, if dBpA for Mac is right around the corner with its checkbox then I don't think it's too big of a deal to put your whole batch-conversion plans off for a bit until you find all the answers you need.
Agreed. Completely.
I expect to be first in line, dollars in hand.
Two weeks is the projected release.
Hi Smok3,
I would really like to try your script, but the download link is dead... is it possible to "repost" it ??
Thanks !
@DJJazzyFred; Tomorrow, have it on another machine as it seems ....
edit: here https://dl.dropboxusercontent.com/u/7953236...ALACcheckV2.zip (https://dl.dropboxusercontent.com/u/79532365/tmp/audioToALACcheckV2.zip)
Good job smok3 on the script and drag&drop interface.
I played with it over the weekend and compared with results that I obtained with a script that I had been working on following this discussion and hints from you and greynol and came with a few questions. (I am using the terminal to call my script and installed ffmpeg and flac with homebrew.)
1.
I converted a bunch of flac files with your script and in terminal using the basic
ffmpeg -i file.flac -acodec alac out.m4a
call and noticed that your script produced significantly larger files, i.e. flacFile=54.7M, your script ALAC=74.7M and basic ffmpeg call ALAC=52.2M. After looking at your script, I noticed that you use the
-compression_level 0
option which seems to be the reason of the larger size.
Is there a reason why you use it other than for speed of conversion ?? My understanding is that the compression level would only speed up the process, but has no effect on quality. As a matter of fact, after computing the md5 for each of the 3 files, they had the same crc, so we can assume the audio was exactly the same.... right ???
2.
You also use
-loglevel warning
sorry for my ignorance, but why exactly ??? (I am not challenging you, just curious since I don't know what it does)
3.
In my script, I am using metaflac to read the md5 from the flac metadata
flacOrigCrc=$(metaflac --show-md5sum "$file.flac")
and then compare it with the calculated flac as an additional security to make sure that the flac file is in good shape, and believe it or not, in my 150 test flacs, I found 3 that were corrupted (probably because of moving from a HD to another of HD faults), so I think that this is an important feature !!!
Like you, I looked around to find a flac binary but couldn't find one. I guess we will have to figure a way to compile it !!!
4.
It is sad that unlike FLAC, the ALAC container doesn't have a metadata tag for the audio md5, so for now, in my script, I write the audio_md5sum in the comment tag, but if somebody knows a way to add custom tags to a m4a file, it would be great to add the checksum under it's own tag. So a very simple check utility could be written to check if the audio part of an ALAC file is corrupted after moving it...
I still have some cleanup to do but I will post my script when it is clean !!!
(and quite honestly smok3, I am taking some parts of yours that are very well thought !!!)
Oh well, somehow i didn't notice the file-bloat, the "-compression_level 0" should fix highbit flac sources in current ffmpeg version (at the time of my writing), but that goes under ffmpeg bugs, so just an ugly workaround and and it seems like it bloats the "normal" ones ..... (to test: try a high bitdepth flac source and see if it breaks with your version of ffmpeg and without "-compression_level 0")
- loglevel warning < I belive it makes ffmpeg a bit less verbose
- The reason I have avoided metaflac is allready noted if you read the thread.
Of course you are free to take whatever you need.
and believe it or not, in my 150 test flacs, I found 3 that were corrupted (probably because of moving from a HD to another of HD faults), so I think that this is an important feature !!!
3 of 150 is a big percentage of a small sample. I think I've had 3 of 50k or something.
and believe it or not, in my 150 test flacs, I found 3 that were corrupted (probably because of moving from a HD to another of HD faults), so I think that this is an important feature !!!
3 of 150 is a big percentage of a small sample. I think I've had 3 of 50k or something.
I know.... i've had some issues with the HD that has my FLACs, so that is why I want to check them before converting to ALAC and moving to a new HD