I'm using Max to rip my CD collection to ALAC format. The ALAC files are imported into iTunes and they play just fine on the machine that did the ripping. However another Macintosh is unable to play the songs remotely using iTunes Sharing. The songs appear in the iTunes browser but after clicking Play the cursor stays stuck at 0:00 and there is no audio.
On the same remote machine using FrontRow the error message is "this song cannot be played".
Back on the first machine, where the ALAC plays just fine, I use the iTunes menu Advanced -> Convert Selection to Apple Lossless. This create a second ALAC file that does play correctly with iTunes Sharing on the remote machine, both in iTunes and FrontRow.
The only differences between the two ALAC files I can see after poking around with Command-I in iTunes are (1) the non-functioning ALAC file doesn't have the Bitrate field, the functioning ALAC file does have a Bitrate field (it's about 900kbps) and (2) the Encoded By field is obviously different (Max vs iTunes).
iTunes Sharing of ALAC doesn't work
Sharing broken
I have the same problem, though in my case I converted my FLAC collection to AAC for use on an iPod. The converted files cannot be shared. They appear to others users, but they won't play.
A possible fix is that when I convert the AAC files I made with MAX to AAC files using iTunes, I can share them. Not sure I want to do this, though, as it's my understanding it will further reduce the quality. iTunes can't read FLAC, so I can't use it to convert my original files.
Did I do something wrong in the conversion process, or does MAX need a tweak so that the files it generates can be shared in iTunes?
Thanks
Chris
A possible fix is that when I convert the AAC files I made with MAX to AAC files using iTunes, I can share them. Not sure I want to do this, though, as it's my understanding it will further reduce the quality. iTunes can't read FLAC, so I can't use it to convert my original files.
Did I do something wrong in the conversion process, or does MAX need a tweak so that the files it generates can be shared in iTunes?
Thanks
Chris
Re: iTunes Sharing of ALAC doesn't work
I think this is related to a magic cookie that the iTunes encoder sets and the Core Audio encoder doesn't. I'm not sure how to make the files Max generates compatible with iTunes sharing, and I honestly don't know why they don't work in the first place. There has been some talk of this issue on these forums before. Perhaps someone should file a bug against iTunes- surely an ALAC file generated with Core Audio should work in iTunes!nathanh wrote:The only differences between the two ALAC files I can see after poking around with Command-I in iTunes are (1) the non-functioning ALAC file doesn't have the Bitrate field, the functioning ALAC file does have a Bitrate field (it's about 900kbps) and (2) the Encoded By field is obviously different (Max vs iTunes).
I think I read somewhere that there are problems with tags and streaming through iTunes. Some older AAC encoders put the tags at the end of the files instead of the front. This meant iTunes could play them locally but on sharing/streaming they wouldn't play on another system. Probably because the other systems expect to be told what they are supposed to play before the actual audio data is send.
Since Max creates AAC's through CoreAudio I don't think it'll be the cause here though. Still, the symptoms are interestingly the same.
Since Max creates AAC's through CoreAudio I don't think it'll be the cause here though. Still, the symptoms are interestingly the same.
Sharing workaround
Found a program called Sharealike at this site:
http://ifthensoftwarehq.blogspot.com/20 ... alike.html
Allows sharing of files in Itunes no matter what program created them, and adds the ability give write access to sharers. Also works with iPhoto. Only works for sharing across user accounts on the same computer, though.
http://ifthensoftwarehq.blogspot.com/20 ... alike.html
Allows sharing of files in Itunes no matter what program created them, and adds the ability give write access to sharers. Also works with iPhoto. Only works for sharing across user accounts on the same computer, though.
Wow - glad to see others are having this problem!
I had a tough time figuring out what was going on! Glad to see I'm not the only one with this problem.
Strangely, I can still stream these songs to my airport express, but I can't play them remotely.
Knowing that all I have to do is reconvert them in iTunes, that's not a big deal. Since I'm using lossless, it shouldn't be a problem.
Here's a suggestion for a possible solution though -
Have an option in Max like "re-encode lossless in iTunes" that will import them into iTunes and then trigger iTunes to re-encode them immediately so they have the 'magic cookie'. I realize this would take longer, but honestly that doesn't matter to me. I batch up a bunch to convert and go live my life, I don't generally sit there twitching to press play as soon as they're done.
Strangely, I can still stream these songs to my airport express, but I can't play them remotely.
Knowing that all I have to do is reconvert them in iTunes, that's not a big deal. Since I'm using lossless, it shouldn't be a problem.
Here's a suggestion for a possible solution though -
Have an option in Max like "re-encode lossless in iTunes" that will import them into iTunes and then trigger iTunes to re-encode them immediately so they have the 'magic cookie'. I realize this would take longer, but honestly that doesn't matter to me. I batch up a bunch to convert and go live my life, I don't generally sit there twitching to press play as soon as they're done.
I've seen this issue before with another application that broke iTunes sharing of AAC/ALAC files.
The same issue also means that AAC/ALAC files encoded by Max probably won't play on an iPod shuffle.
It is caused by the order of the atoms in the AAC file.
If you use Atomic Parsley to display and compare the atoms in an AAC file encoded by iTunes and an AAC file encoded by Max, you should find the following:
A file encoded by iTunes will have the following order of atoms:
ftyp
moov - contains the file tags and other information
free
mdat - contains the encoded music
A file encoded by Max has the following order of atoms:
ftyp
free
mdat
moov
iTunes sharing and the iPod shuffle need the moov atom before the mdat item.
To test this theory out I encoded a file as AAC using Max. The file wouldn't play using iTunes sharing.
I then processed the file using AtomicParsley with the --freefree option which deletes free space in the file and re-orders the atoms with the same order as iTunes encoded files (ftyp, moov, mdat).
The file would then play using iTunes sharing.
I came across this with another application MusicIP that adds custom atoms to files. It did this by changing the existing atoms to free space then tacked on these atoms with the custom atom to the end of the file. This broke iTunes sharing and playing the tracks on the iPod shuffle.
To fix this issue Max should encode files with the same order of atoms used in iTunes.
The same issue also means that AAC/ALAC files encoded by Max probably won't play on an iPod shuffle.
It is caused by the order of the atoms in the AAC file.
If you use Atomic Parsley to display and compare the atoms in an AAC file encoded by iTunes and an AAC file encoded by Max, you should find the following:
A file encoded by iTunes will have the following order of atoms:
ftyp
moov - contains the file tags and other information
free
mdat - contains the encoded music
A file encoded by Max has the following order of atoms:
ftyp
free
mdat
moov
iTunes sharing and the iPod shuffle need the moov atom before the mdat item.
To test this theory out I encoded a file as AAC using Max. The file wouldn't play using iTunes sharing.
I then processed the file using AtomicParsley with the --freefree option which deletes free space in the file and re-orders the atoms with the same order as iTunes encoded files (ftyp, moov, mdat).
The file would then play using iTunes sharing.
I came across this with another application MusicIP that adds custom atoms to files. It did this by changing the existing atoms to free space then tacked on these atoms with the custom atom to the end of the file. This broke iTunes sharing and playing the tracks on the iPod shuffle.
To fix this issue Max should encode files with the same order of atoms used in iTunes.
mikerob, that is some serious sleuthing! Kudos to you for figuring this out.
I will run some experiments to see how/when/if the atoms are changing. When Max encodes an AAC file, it uses CoreAudio to do the actual encoding and then uses the mp4v2 library for tagging. I'm curious to know if the atom order generated by CoreAudio works with iTunes and mp4v2 is re-ordering them, or vice-versa (or neither?).
I will run some experiments to see how/when/if the atoms are changing. When Max encodes an AAC file, it uses CoreAudio to do the actual encoding and then uses the mp4v2 library for tagging. I'm curious to know if the atom order generated by CoreAudio works with iTunes and mp4v2 is re-ordering them, or vice-versa (or neither?).
Test results
If I remove the tagging code entirely and encode an AAC file using CoreAudio here are the atoms:
When I add the metadata code back in and encode the same file the result is:
So it seems the "problem" (I hesitate to call it a problem with Max, because it seems that the source of the problem is really incorrect handling of the MP4 atoms by iTunes/iPod) might be with using mp4v2. I will see if there are some options to pass to the library to handle re-ordering or deletion of the offending atoms.
Code: Select all
Atom ftyp @ 0 of size: 28, ends @ 28
Atom moov @ 28 of size: 77977, ends @ 78005
Atom mvhd @ 36 of size: 108, ends @ 144
Atom iods @ 144 of size: 33, ends @ 177
Atom trak @ 177 of size: 77828, ends @ 78005
Atom tkhd @ 185 of size: 92, ends @ 277
Atom mdia @ 277 of size: 77728, ends @ 78005
Atom mdhd @ 285 of size: 32, ends @ 317
Atom hdlr @ 317 of size: 37, ends @ 354
Atom minf @ 354 of size: 77651, ends @ 78005
Atom smhd @ 362 of size: 16, ends @ 378
Atom dinf @ 378 of size: 36, ends @ 414
Atom dref @ 386 of size: 28, ends @ 414
Atom stbl @ 414 of size: 77591, ends @ 78005
Atom stts @ 422 of size: 24, ends @ 446
Atom stsd @ 446 of size: 103, ends @ 549
Atom mp4a @ 462 of size: 87, ends @ 549
Atom esds @ 498 of size: 51, ends @ 549
Atom stsz @ 549 of size: 38716, ends @ 39265
Atom stsc @ 39265 of size: 40, ends @ 39305
Atom stco @ 39305 of size: 38700, ends @ 78005
Atom mdat @ 78005 of size: 7280305, ends @ 7358310
------------------------------------------------------
Total size: 7358310 bytes; 21 atoms total. AtomicParsley version: 0.8.8 (utf8)
Media data: 7280305 bytes; 78005 bytes all other atoms (1.060% atom overhead).
Total free atoms: 0 bytes; 0.000% waste.
------------------------------------------------------Code: Select all
Atom ftyp @ 0 of size: 28, ends @ 28
Atom free @ 28 of size: 77977, ends @ 78005
Atom mdat @ 78005 of size: 7280305, ends @ 7358310
Atom mdat @ 7358310 of size: 8, ends @ 7358318
Atom moov @ 7358318 of size: 78349, ends @ 7436667
Atom mvhd @ 7358326 of size: 108, ends @ 7358434
Atom iods @ 7358434 of size: 33, ends @ 7358467
Atom trak @ 7358467 of size: 77828, ends @ 7436295
Atom tkhd @ 7358475 of size: 92, ends @ 7358567
Atom mdia @ 7358567 of size: 77728, ends @ 7436295
Atom mdhd @ 7358575 of size: 32, ends @ 7358607
Atom hdlr @ 7358607 of size: 37, ends @ 7358644
Atom minf @ 7358644 of size: 77651, ends @ 7436295
Atom smhd @ 7358652 of size: 16, ends @ 7358668
Atom dinf @ 7358668 of size: 36, ends @ 7358704
Atom dref @ 7358676 of size: 28, ends @ 7358704
Atom stbl @ 7358704 of size: 77591, ends @ 7436295
Atom stts @ 7358712 of size: 24, ends @ 7358736
Atom stsd @ 7358736 of size: 103, ends @ 7358839
Atom mp4a @ 7358752 of size: 87, ends @ 7358839
Atom esds @ 7358788 of size: 51, ends @ 7358839
Atom stsz @ 7358839 of size: 38716, ends @ 7397555
Atom stsc @ 7397555 of size: 40, ends @ 7397595
Atom stco @ 7397595 of size: 38700, ends @ 7436295
Atom udta @ 7436295 of size: 372, ends @ 7436667
Atom meta @ 7436303 of size: 364, ends @ 7436667
Atom hdlr @ 7436315 of size: 33, ends @ 7436348
Atom ilst @ 7436348 of size: 319, ends @ 7436667
Atom ©alb @ 7436356 of size: 52, ends @ 7436408
Atom data @ 7436364 of size: 44, ends @ 7436408
Atom ©ART @ 7436408 of size: 35, ends @ 7436443
Atom data @ 7436416 of size: 27, ends @ 7436443
Atom gnre @ 7436443 of size: 26, ends @ 7436469
Atom data @ 7436451 of size: 18, ends @ 7436469
Atom ©day @ 7436469 of size: 28, ends @ 7436497
Atom data @ 7436477 of size: 20, ends @ 7436497
Atom ©cmt @ 7436497 of size: 34, ends @ 7436531
Atom data @ 7436505 of size: 26, ends @ 7436531
Atom ©nam @ 7436531 of size: 70, ends @ 7436601
Atom data @ 7436539 of size: 62, ends @ 7436601
Atom trkn @ 7436601 of size: 32, ends @ 7436633
Atom data @ 7436609 of size: 24, ends @ 7436633
Atom ©too @ 7436633 of size: 34, ends @ 7436667
Atom data @ 7436641 of size: 26, ends @ 7436667
------------------------------------------------------
Total size: 7436667 bytes; 43 atoms total. AtomicParsley version: 0.8.8 (utf8)
Media data: 7280305 bytes; 156362 bytes all other atoms (2.103% atom overhead).
Total free atoms: 77977 bytes; 1.049% waste.
------------------------------------------------------this is a real kick in the kahoenies
I just tried to set up my home network the past few days to share my iTunes Apple Lossless files around my house and couldn't figure out why the songs wouldn't play. Now I find out why. 
Has anybody figured out how to do this without re-ripping the 1000 CDs I've already done other than using iTunes to convert the m4a files that max created into m4a files that it creates, which by the way is incredibly slow.
It also creates a file of a slightly different size. Are they still lossless after a double conversion?
This bug should be clearly posted in the MAX program where it can't be missed. I also see from other posts that these files won't work on an iPod? I don't hesitate to call it a problem with Max since it creates files that aren't completely compatible with the number one music player in the world that it boasts compatibility with. I know it is hard to bitch about something that is free, but it is frustrating to find out now that the hundreds of hours I spent ripping will need to be redone.
Has anybody figured out how to do this without re-ripping the 1000 CDs I've already done other than using iTunes to convert the m4a files that max created into m4a files that it creates, which by the way is incredibly slow.
It also creates a file of a slightly different size. Are they still lossless after a double conversion?
This bug should be clearly posted in the MAX program where it can't be missed. I also see from other posts that these files won't work on an iPod? I don't hesitate to call it a problem with Max since it creates files that aren't completely compatible with the number one music player in the world that it boasts compatibility with. I know it is hard to bitch about something that is free, but it is frustrating to find out now that the hundreds of hours I spent ripping will need to be redone.
Re: this is a real kick in the kahoenies
The issue that means AAC/ALAC file sharing doesn't work should also mean that these tracks won't play on an iPod Shuffle - other types of iPod should be ok.
I don't yet use Max for ripping CDs but came across the file sharing issue with another application that treated the track tag information in a similar fashion to Max.
To fix this, I used an application called AtomicParsley
AtomicParsley is purely a command line program that you run using the Mac terminal so it isn't that user-friendly.
It is very powerful with lots of options but the only thing you need to do to fix the files is run AtomicParsley from the command line as follows:
/pathtoatomicparsley/AtomicParsley /pathtotrack -F -W
The -F option deletes free space in the track and re-orders the track's tag information in the order required for file sharing and the iPod shuffle.
The -W option (overwrite) writes the new file to a temp file, deletes the original and renames the new file to the orginal's name. If you wanted to keep the original, use -o <newfilename> instead of -W
There is a forum for users of AtomicParsley and the developers are usually helpful and responsive.
btw using iTunes to re-encode an ALAC file as ALAC will still mean the file is lossless. However there will likely be some iTunes specific information in the tags and iTunes may leave a different amount of free space in the file so the size of the Max file and iTunes file almost certainly won't be the same.
I don't yet use Max for ripping CDs but came across the file sharing issue with another application that treated the track tag information in a similar fashion to Max.
To fix this, I used an application called AtomicParsley
AtomicParsley is purely a command line program that you run using the Mac terminal so it isn't that user-friendly.
It is very powerful with lots of options but the only thing you need to do to fix the files is run AtomicParsley from the command line as follows:
/pathtoatomicparsley/AtomicParsley /pathtotrack -F -W
The -F option deletes free space in the track and re-orders the track's tag information in the order required for file sharing and the iPod shuffle.
The -W option (overwrite) writes the new file to a temp file, deletes the original and renames the new file to the orginal's name. If you wanted to keep the original, use -o <newfilename> instead of -W
There is a forum for users of AtomicParsley and the developers are usually helpful and responsive.
btw using iTunes to re-encode an ALAC file as ALAC will still mean the file is lossless. However there will likely be some iTunes specific information in the tags and iTunes may leave a different amount of free space in the file so the size of the Max file and iTunes file almost certainly won't be the same.
thanks for the info
Is "pathtotrack" just the path to the directory where the files exist, or does this command need to be run and include the file name for each and every track? With over 1000 CDs and probably 10,000 tracks I can't type in the command line for every track.
Thanks
Thanks
Re: thanks for the info
Perhaps you can use ID Infiltr8 tp batch process all your files?herman wrote: With over 1000 CDs and probably 10,000 tracks I can't type in the command line for every track.