AudioDoctor Posted May 23, 2012 Share Posted May 23, 2012 I recently changed some of the options to view files in iTunes and suddenly realized that some of my music is incorrectly ripped at 24/44 instead of 16/44. Example below: Now the question is, do I re-rip them correctly, do I resample them down to 16/44, or do I leave them alone? No electron left behind. Link to comment
AlainGr Posted May 23, 2012 Share Posted May 23, 2012 Hi, I think that since the additional 8 bits are padded with zeros, it does not really impact SQ. Some DACs seem to appreciate more 24 bits than 16 and I have seen many music players suggesting to adjust the bit depth to 24 bits... The only drawback I can think of is that it takes more space on your drive... Alain Link to comment
One and a half Posted May 23, 2012 Share Posted May 23, 2012 Did you iTunes for ripping? It has a bug to do with AIFF if you have 24bit material it will truncate to 16 bit which is not good. Not sure if they fixed that either. There's no music information, so it just takes up a little more space on HDD. I'd leave them as is. AS Profile Equipment List Say NO to MQA Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 Did you iTunes for ripping? It has a bug to do with AIFF if you have 24bit material it will truncate to 16 bit which is not good. Not sure if they fixed that either. There's no music information, so it just takes up a little more space on HDD. I'd leave them as is. No, I am pretty sure these are rips done with Max and I probably set something wrong. Both DACs I have are 24 bit, so it should not be affecting sound quality any as far as I know, but I thought I would ask anyway. No electron left behind. Link to comment
wgscott Posted May 23, 2012 Share Posted May 23, 2012 I guess it is possible it dithered it to 24 bits, in which case you should leave it alone. If you ripped to ALAC in iTunes, you wouldn't have this problem, and you could save disk space... Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 I guess it is possible it dithered it to 24 bits, in which case you should leave it alone. If you ripped to ALAC in iTunes, you wouldn't have this problem, and you could save disk space... everyone knows letting iTunes do the ripping is inferior... here are my current settings, as you can see 24bit is an option... No electron left behind. Link to comment
Paul R Posted May 23, 2012 Share Posted May 23, 2012 I recently changed some of the options to view files in iTunes and suddenly realized that some of my music is incorrectly ripped at 24/44 instead of 16/44. Example below: [ATTACH=CONFIG]524[/ATTACH] Now the question is, do I re-rip them correctly, do I resample them down to 16/44, or do I leave them alone? Naw- they are just fine. Sending them to your DAC extends them to 24bits anyway. -Paul Anyone who considers protocol unimportant has never dealt with a cat DAC. Robert A. Heinlein Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 Naw- they are just fine. Sending them to your DAC extends them to 24bits anyway. -Paul That is a very good point Paul. No electron left behind. Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 Hi, I think that since the additional 8 bits are padded with zeros, it does not really impact SQ. Some DACs seem to appreciate more 24 bits than 16 and I have seen many music players suggesting to adjust the bit depth to 24 bits... The only drawback I can think of is that it takes more space on your drive... Are you sure it just padded zeros in there? No electron left behind. Link to comment
spdif-usb Posted May 23, 2012 Share Posted May 23, 2012 Truncate them down to 16-bit using SoX and then if they turn out to be bit-identical to your re-rips you'll immediately know it's working alright. If you had the memory of a goldfish, maybe it would work. Link to comment
AlainGr Posted May 23, 2012 Share Posted May 23, 2012 The few software players I have seen suggest to increase the bit depth to 24 bits. And thinking about it, when playing, if someone decides to upsample the music in the PC instead of in DAC, it will be increased to 24 bits anyway. I guess it will be the same when oversampling occurs in the DAC (if not done by the software player). But yes the additional bits are padded with zeros Alain Link to comment
Daudio Posted May 23, 2012 Share Posted May 23, 2012 everyone knows letting iTunes do the ripping is inferior... There is nothing wrong with ripping in iTunes as long as "Use error correction" is checked ! Link to comment
Paul R Posted May 23, 2012 Share Posted May 23, 2012 Yep - I would lay quite a bit of money, they are zeros. It would take some serious computational power to extend a 16 bit CD to 24 bits with meaningful data rather than just pad the sample size. You can dump one of the music files out to check and be sure if you would like. Open a wide Terminal window and type the following command (without the quotes): " hexdump -C <name of music file> | more ". Rerip a track in 16 bit and compare the values. The first bytes are the header information, and should identify the file type. Like this: 00000000 46 4f 52 4d 02 49 c6 8e 41 49 46 46 43 4f 4d 4d |FORM.I<C6>.AIFFCOMM| 00000010 00 00 00 12 00 02 00 92 71 98 00 10 40 0e ac 44 |........q...@.<AC>D| 00000020 00 00 00 00 00 00 53 53 4e 44 02 49 c6 68 00 00 |......SSND.I<C6>h..| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0000f910 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff |......<FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>| 0000f920 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |<FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>| 0000f930 ff ff ff ff ff ff 00 00 ff ff 00 00 ff ff 00 00 |<FF><FF><FF><FF><FF><FF>..<FF><FF>..<FF><FF>..| 0000f940 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 |<FF><FF>..<FF><FF>..<FF><FF>..<FF><FF>..| 0000f950 fe ff 00 00 fe ff 00 00 fe ff 00 00 fe ff 00 00 |<FE><FF>..<FE><FF>..<FE><FF>..<FE><FF>..| * 0000f9b0 fe ff 00 00 fd ff 00 00 fe ff 00 00 fd ff 00 00 |<FE><FF>..<FD><FF>..<FE><FF>..<FD><FF>..| 0000f9c0 fd ff 00 00 fd ff 00 00 fd ff 00 00 fd ff 00 00 |<FD><FF>..<FD><FF>..<FD><FF>..<FD><FF>..| You should be able to see extra zeros padding out the data in the 24bit version. Each character above in the left hand number fields represents one byte (8 bits). Takes three of them to make up a 24bit sample. It won't be aligned perfectly as it would be with 16 or 32 bit data. -Paul Anyone who considers protocol unimportant has never dealt with a cat DAC. Robert A. Heinlein Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 There is nothing wrong with ripping in iTunes as long as "Use error correction" is checked ! I was kidding... No electron left behind. Link to comment
AudioDoctor Posted May 23, 2012 Author Share Posted May 23, 2012 Yep - I would lay quite a bit of money, they are zeros. It would take some serious computational power to extend a 16 bit CD to 24 bits with meaningful data rather than just pad the sample size. You can dump one of the music files out to check and be sure if you would like. Open a wide Terminal window and type the following command (without the quotes): " hexdump -C <name of music file> | more ". Rerip a track in 16 bit and compare the values. The first bytes are the header information, and should identify the file type. Like this: 00000000 46 4f 52 4d 02 49 c6 8e 41 49 46 46 43 4f 4d 4d |FORM.I<C6>.AIFFCOMM| 00000010 00 00 00 12 00 02 00 92 71 98 00 10 40 0e ac 44 |........q...@.<AC>D| 00000020 00 00 00 00 00 00 53 53 4e 44 02 49 c6 68 00 00 |......SSND.I<C6>h..| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 0000f910 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff |......<FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>| 0000f920 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |<FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>| 0000f930 ff ff ff ff ff ff 00 00 ff ff 00 00 ff ff 00 00 |<FF><FF><FF><FF><FF><FF>..<FF><FF>..<FF><FF>..| 0000f940 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 |<FF><FF>..<FF><FF>..<FF><FF>..<FF><FF>..| 0000f950 fe ff 00 00 fe ff 00 00 fe ff 00 00 fe ff 00 00 |<FE><FF>..<FE><FF>..<FE><FF>..<FE><FF>..| * 0000f9b0 fe ff 00 00 fd ff 00 00 fe ff 00 00 fd ff 00 00 |<FE><FF>..<FD><FF>..<FE><FF>..<FD><FF>..| 0000f9c0 fd ff 00 00 fd ff 00 00 fd ff 00 00 fd ff 00 00 |<FD><FF>..<FD><FF>..<FD><FF>..<FD><FF>..| You should be able to see extra zeros padding out the data in the 24bit version. Each character above in the left hand number fields represents one byte (8 bits). Takes three of them to make up a 24bit sample. It won't be aligned perfectly as it would be with 16 or 32 bit data. -Paul That looks like a pretty good way to cure my audiophile neuroses. No electron left behind. Link to comment
AudioDoctor Posted May 24, 2012 Author Share Posted May 24, 2012 Paul, I can't get your command to work in Terminal? No electron left behind. Link to comment
Paul R Posted May 24, 2012 Share Posted May 24, 2012 Can you post the message on the screen you get when you try the command? Probably something simple. -Paul Anyone who considers protocol unimportant has never dealt with a cat DAC. Robert A. Heinlein Link to comment
AudioDoctor Posted May 24, 2012 Author Share Posted May 24, 2012 Can you post the message on the screen you get when you try the command? Probably something simple. -Paul Yeah, I can do that. edit: could it be because I am not running the Mini in an administrator account? No electron left behind. Link to comment
AlainGr Posted May 24, 2012 Share Posted May 24, 2012 I think that the command is OK, but not the name of the file. To allow the OS to interpert your title as 1 file, you need to put the title of the song between the ' sign (at beginning and end of the song, INCLUDING the extension (example: 'Dance Me to the End of Love.aif') Since OS-X is made of Unix, it is case sensitive and the reason for the ' is that the spaces are interpreted as a different file. So, Dance Me to the End of Love is considered as 7 different files, while 'Dance Me to the End of Love.aif' between the ' sign is considered as one file... Hope it will work... Alain Link to comment
AudioDoctor Posted May 25, 2012 Author Share Posted May 25, 2012 I think that the command is OK, but not the name of the file. To allow the OS to interpert your title as 1 file, you need to put the title of the song between the ' sign (at beginning and end of the song, INCLUDING the extension (example: 'Dance Me to the End of Love.aif') Since OS-X is made of Unix, it is case sensitive and the reason for the ' is that the spaces are interpreted as a different file. So, Dance Me to the End of Love is considered as 7 different files, while 'Dance Me to the End of Love.aif' between the ' sign is considered as one file... Hope it will work... I tried that, here is what I got... No electron left behind. Link to comment
AlainGr Posted May 25, 2012 Share Posted May 25, 2012 Hi, Sorry... It has been a long time since I worked with Unix... I am quite sure though that a file without spaces should work without any sign. The trick would be to remove the spaces... Can you do a "ls -l Dance*.aif* just to see if the file is where you are attempting to do the hexdump command ? I will do some checking on my side for the next minutes to see if there are any other signs that can enclose the file... Alain Alain Link to comment
AlainGr Posted May 25, 2012 Share Posted May 25, 2012 Hi again, I do not have any Unix (nor Linux) OS here... I could suggest some other attempts, but I would feel silly to ask you to do this, then do that, until it works... I guess that Paul will be a lot better at this than I... There are suggestions on the net after I googled "how to work on a file with spaces in filename (unix bash)" I got this... Bash Scripting Tip: processing filenames with spaces - Mecworks I realize that a filename with spaces is not... Easy to work with... Alain Alain Link to comment
goldsdad Posted May 25, 2012 Share Posted May 25, 2012 Doc, Open Terminal. Copy without the quotes "hexdump -C ". Be sure to include the space after "C". Paste it into the Terminal window and do not press the enter key yet. Drag and drop your file from Finder into the Terminal window. That will put the file's full path with escaped spaces onto the command line. Do not press enter yet. Copy and paste without the quotes " | more" into the Terminal window. Now press the enter key. The Terminal window will fill with the first page of hexdump output. Press spacebar to advance one page, repeating hundreds of times until you are at the beginning of the actual audio samples. Now start checking whether every third pair of hexadecimal digits is zero zero. No, I don't think you want to do that. There are other ways to check whether all 24-bit samples in a file contain only zero in the least significant byte. One way is to create a 16-bit truncated version of the suspect 24-bit file, zero-pad that back up to 24-bit, make a raw PCM conversion (i.e. no metadata, etc., just audio samples) of each of these two 24-bit files then use the UNIX diff utility to compare the raw files. diff will produce a result within a couple of seconds. If the result of diff is null then the suspect file is zero-padded, otherwise diff will tell you that the files don't match, therefore the suspect file is not zero-padded. Max can do the truncation, zero padding and raw conversions. Run diff in Terminal. On the other hand, here's a link to how to check for zero-padding in Audacity: #22 Link to comment
AudioDoctor Posted May 25, 2012 Author Share Posted May 25, 2012 Goldsdad, I followed your instructions, and they worked. I got this, similar to Pauls screenshot above. I will try the other ideas in a bit. No electron left behind. Link to comment
Paul R Posted May 25, 2012 Share Posted May 25, 2012 Yep - it was probably something to do with the filename. I never tried the drag/drop bit with a terminal window. The other options Owen suggested look interesting, but the data is always the real bottom line, and this is a simple way to look at it for sure. The third section down, starting at offset 18870, shows the music data, and it is clearly zero padded. -Paul Anyone who considers protocol unimportant has never dealt with a cat DAC. Robert A. Heinlein Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now