Try this applescript, available at versiontracker.
Make Mine MPEG-4 v3.5.1
Works great and it's cheap!
Peter Lehrack
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iTunes 3
- Thread starter arn
- Start date
- Sort by reaction score
Try this applescript, available at versiontracker.
Make Mine MPEG-4 v3.5.1
Works great and it's cheap!
Peter Lehrack
Huh? The GIF format is lossless compression. Unless you're talking about lack of color space (most GIFs are 256 colors palatted, so obviously you're going to lose colors if your TIFF isn't 256 colors), in which case that's what you should be talking about, not GIF vs JPEG/TIFF.
Down-shifting the color space will cause loss of information. The GIF format and compression routines will not.
On the other hand, taking a 16-color bitmap, "compressing" it with JPEG, and then converting it to GIF will result in a much uglier result than taking the original 16-color bitmap and going to GIF with it. And that *is* because of lossless compression.
peterjhill
macrumors 65816
Imagine if you will...
Photos Music
TIFF AIFF
GIF MP3
JPEG MP4
You need to use your imagination here. tiff and aiff are pretty much uncompressed photos and audio formats. GIF and JPEG are two different means of compressing a photo. Sure, a GIF is lossless, if you feed it a photo that is less than 256 colors, but if you take a photograph, chances are it will have more than 256 colors. jpeg is another means of compressing files, that uses a different scheme. MP3 and MP4 use much different means to compress audio.
So, converting a photograph of the grand canyon that is in uncompressed TIFF format, with a 24 or 32 bit color range to GIF will cause a loss of original data. To me, lossless implies being able to take a compressed file and restore it to its original format without any loss of data. Maybe you think that the color space change is different, I see it as two different methods to attempt to do the same thing.
So converting a tiff to a gif and then the gif to a jpeg would be silly. In the same manner, converting an aiff to an mp3 then to an mp4 would also be silly. It also probably would not be any faster than re-encoding the original cds. It might actually take longer to convert an mp3 to an mp4. Typically the process is limited by the CPU and not the spindle speed.
IMHO
peterjhill
macrumors 65816
no idea really. I have a shortcut to "search for new posts" and saw the thread. I thought there was something about a new update to itunes, it took me a few seconds to realize that this is old news. It is completely random that the post was refering to one of my comments
madamimadam
macrumors 65816
You have a different oppinion to the people who develop the terms, then, unless you add loss to a GIF (like programs like PhotoShop let you do) GIF is lossless. While there might be less colours, there is no loss in the clarity of the image (to an extent).
excellent! and here i was, thinking i was the only one...
i have my blue and white g3 holding court in my living room, where it's a music studio centerpiece as well as the "tv" (formac studio and a vcr attached) and general goofy-looking entertainment unit, aside from being the main computer in my digs (sort of the late 20th century equivalent of a philco television); i've got a turntable that's wired into my mixer for recording loops, etc.; have always thought it was a little lame that at parties, i can't have itunes visuals syncing with the external input material b/c it only works with the internal stuff or the cd-drive.
i think your idea would be a great improvement, and moreover it really makes sense as part of apple's "hub" strategy, if such an idea still has any currency in cupertino...
madamimadam
macrumors 65816
While it is not iTunes doing the syncing, G-Force has a standalone program that will read the external audio source.
Well, This is not necessarily true. In any given mp3, the lows and highs that are left out in the incoding process, are already gone. So when it is reencoded into mp3 format, you don't have to worry about losing them a second time. As long as good decoding and encoding software is used. It is possible to go through this proccess as many times as you wish, without losing any additional quality. Unless, of course, you have some sort of hardware failier.[/
madamimadam
macrumors 65816
Otherwise, how could you have 128Kb of information after re-encoding a 128Kb MP3 if you have dropped data... right?!
springscansing
macrumors 6502a
Re: I hope it's got a lot of the bad/lack of features sorted out this time !
Okay! Let's go!
No record audio input option, this is a pretty basic feature and it's hardly a way of organising you're music library if you can't transfer from tape/vinyl and other sources easily. Obviously even if you could, the concept of "Organising" by any means in iTunes is laughable to say the least
I hope you are aware that this would require more than a record button.. you'd have to be able to normalize the recordings, adjust input levels, etc. I'd rather them not clutter iTunes with such things, as it would confuse a lot of people. There's a TON of freeware that can do this already.
Add an album to the playlist, not only won't it play them in order but sorting by artist will throw the play order off even more. If you've encoded several albums by an artist, it won't keep them in album order or track order.
I've got over 10Gb of MP3s, all in folders named by artist and album, they have the track numbers in the file name too, nothing plays back in the correct order, absolutely nothing. I've tried adding the folders using the menu and it's just as disorganised as dragging them over the iTunes window.
You obviously are doing something wrong here, as I've encoded several albums direct from CDs and they all play in order. Are you SURE you have the track numbers in there? I've never heard of this problem.
As for the rest of your complaints, they're either trivial or silly (I mean common, the text sizes are fine in my opinion... they want them to look good smoothed, remember? heh).
iTunes is BY FAR the best mp3 player available... ease up man. And use the right 'your's next time, hehe.
Okay! Let's go!
No record audio input option, this is a pretty basic feature and it's hardly a way of organising you're music library if you can't transfer from tape/vinyl and other sources easily. Obviously even if you could, the concept of "Organising" by any means in iTunes is laughable to say the least
I hope you are aware that this would require more than a record button.. you'd have to be able to normalize the recordings, adjust input levels, etc. I'd rather them not clutter iTunes with such things, as it would confuse a lot of people. There's a TON of freeware that can do this already.
Add an album to the playlist, not only won't it play them in order but sorting by artist will throw the play order off even more. If you've encoded several albums by an artist, it won't keep them in album order or track order.
I've got over 10Gb of MP3s, all in folders named by artist and album, they have the track numbers in the file name too, nothing plays back in the correct order, absolutely nothing. I've tried adding the folders using the menu and it's just as disorganised as dragging them over the iTunes window.
You obviously are doing something wrong here, as I've encoded several albums direct from CDs and they all play in order. Are you SURE you have the track numbers in there? I've never heard of this problem.
As for the rest of your complaints, they're either trivial or silly (I mean common, the text sizes are fine in my opinion... they want them to look good smoothed, remember? heh).
iTunes is BY FAR the best mp3 player available... ease up man. And use the right 'your's next time, hehe.
springscansing
macrumors 6502a
Well, in all fairness, many people can hear the difference. Most likely though, your method of reproduction (cheap PC speakers/cheap headphones) does 100x more damage than mp3 encoding, so you can't notice it.
springscansing
macrumors 6502a
This is incorrect. Continual encoding and decoding does degrade quality. When the compressor goes back over the second time, there's different data in that aiff file than the first time, hence you will get a different output. mp3 enocoding is far more complex than low and hi shelving EQs.
springscansing
macrumors 6502a
And just for the record, encoding mp3s to mp4s takes even longer than encoding directly from the album (as they have to be converted to raw aiff files first anyway), and reading from the disc takes a few seconds. Anyway, the new mp4s will sound WORSE than the mp3s they were encoded from if you go from mp3 to mp4. The files will be smaller though. Who's really having trouble with a packed HD nowadays anyway that convertings mp3 to mp4s would fix? The ability to convert mp3s to mp4s would be a stupid feature.
springscansing
macrumors 6502a
What you say is only correct if you transform digital audio to analog, and then back again to digital. Every time you go through this process quality will be lost. It is, however, very possible to transform a compressed digital audio file into another form of a compressed digital audio file without losing any quality, what so ever, as long as the software is specific enough.
As long as a file can be broken down into idividual bits of information, and these bits can be used indiviually to produce specific sounds. Taking each one of these individual sounds, I can then use them as samples and reproduce them identically on the bit level, into another encoded format. When this transformation is done on a bit by bit basis, it is impossible to lose information. Unless, of coarse, a mistake is made by the person, or the software, doing the transformation.
If programs that perform these sorts of tasks, don't infact, produce a file with identical quality to the original. It is due to a weakness in the software, caused by the authors lack of knowledge, or desire.
As long as the codec is the same, and you are only changing the wrapper (say, from a QuickTime wrapper over MP4 to an AVI wrapper over MP4), this is true. But that's not going through a decode/code cycle, it is just repackaging the bits.
I am not sure what you mean by transforming the digital audio to analog. While a true D/A + A/D conversion cycle would obviously cause signal degradation (that is patently obvious, right?), I don't think anyone here is suggesting such. Going from MP3 -> WAV (PCM encoding, which is not analog) -> MP3 is known to cause signal degradation.
You can see this visually as well. Take a JPEG image, convert it to TIFF. Convert back to JPEG (same quality setting). Do a file diff: are the original and recoded JPEG files bit-for-bit identical? No, they are not. Some information has been lost (by definition, if the round-tripped file is not bit-identical with the original in the same compression format). Look at them: do they look pretty similar? Of course they do. Repeat the process ten times, however, and you'll likely start noticing differences. Repeat it a hundred times and you'll definitely see differences (I'm not sure if OS X has the JPG-tiff command-line conversion tools or not, but you should be able to download them and build them for OS X fairly quickly, or just go to a Linux box ... writing a script to do 100 round-trip conversions would be an extremely simple matter).
Understand two terms:
Lossless: a decoding/encoding round trip of encoded data will not result in loss of data. Encoding of unencoded data may result in a loss of data due to the format's limitations; re-encodings are guaranteed to retain all data. This is the type of encoding most commonly desired for editing applications.
Lossy: a decoding/encoding round trip of encoded data will result in loss of some data. Editing applications generally avoid such formats as each edit/save cycle will lose more data.
JPEG is lossy. It loses information on compression, and it loses information on a round-trip JPEG-to-JPEG recompression. MP3 is very similar in its lossy-ness.
PCM is not lossy. Going from non-PCM to PCM will lose information that the format can not handle, but a round-trip PCM-to-PCM recompression does not lose additional information.
Going back to earlier, someone was comparing GIF to MP3, which is a very bad comparison as, again, by definition, GIF is not lossy. Yes, going from a 32-bit TIFF to 8-bit-palletted GIF is obviously going to lose data (see the definitions above). But GIF-to-GIF recompression will not lose any additional information.
Basically, if you could take an existing MP3 file, convert it to any other encoding (ie, not the MP3 codec, not just change the wrapper) then re-encode it as MP3, and end up with a bit-for-bit identical file as that which with you started, then MP3 would not be a lossy format. It would be lossless compression. That, my friend, would be a really neat trick, and would be a tremendous surprise to the MPE Group that developed the MP3 standard.
Lossy compression introduces artifacts. Visually, take a boldly-colored cartoon drawing and encode it at a low quality setting in JPEG; notice the halos, etc. Steps are taken to reduce the effects of the artifacts, but many survive nonetheless.
Recompressing data that has "artifacts", the compressing engine can not know if the "artifacts" were supposed to be there or not, and so instead of trying to "diminish" the artifacts, it tries to keep them accurate, which in turn introduces other artifacts (why? Because of the nature of the calculations involved, and the purposeful performance-related optimizations built into the standard ... though obviously there is a way to encode the data that is 100% identical to the source data, finding that particular combination again would take an inordinate amount of processing). Such artifacts multiply through multiple recoding cycles.
It's like the guy who walked into the barber and asked him to cut one side shorter than the other, and shave a bald spot just off center on the top of his head. When the barber told him he could not do such a thing, the man responded, "but you did it last time!"
With an infinite amount of computing power and time, and a codec that is specifically designed to allow round-trip recompression, yes, re-encoding MP3 to MP3 could theoretically be mostly lossless. But that was never the intention of MP3, and it is not even a real-world reasonably useful trait for a codec (if you want the original compressed data, just copy the original file directly instead of decompressing/recompressing).
Back to the point: Going from MP3 to AAC, there is not necessarily a way for AAC to properly reproduce the artifacts introduced in MP3, no matter how much time and effort is expended in tring to find such. Thus, the artifacts will find themselves surrounded by secondary artifacts, and the resulting AAC will, by definition and in the absense of extraordinary luck, be a less faithful reproduction of the original than the MP3.
For computers that existed during the time that todays common compression methods were created. Perhaps it would have taken an inordinate amount of processing power, But according to todays standards of processors, this is so, not true, especially with the processing power that is being achieved with pc's.
It's time for new compression methods, for both audio, and video. Which both, are so very possible to create.
Their creation is not limited by posibility, because it can most certainly be done, but rather, by will.
It is not due so much to the nature of the calculations involved, but more so, to the lack of much needed calculations
I admit that the smaller you try to compress a digital file, the harder it is to retain quality. So compression ratio is the real issue, when it comes to quality loss. Because, don't forget, even with a common archiving program, a wave, or aiff file can be compressed to about 42.5 percent of it's original size, and when it is uncompressed it produces an exact replica of the original file.
So why don't you go do that? If you're capable of doing it, shouldn't you be putting up? And if you're not capable of doing it, then how can you know that what you want is possible and that lack of will is the reason it isn't happening?
There's obviously quite a lot of will to create more efficient compression schemes. If there weren't, we wouldn't be seeing MPEG 4.
But compression is tricky; If you stick to purely lossless schemes, you aren't likely to do much better than 50% -- and in some cases, it'll do *much* worse. (If you feed random data into a lossless compression algorithm, the 'compressed' version will, on average, be larger than the original. It's mathematically impossible for a lossless compression algorithm to produce an output smaller than its input when given random data.)
And once you go to lossy, a big, difficult question immediately rears its head: How do you decide what to 'lose'? It seems obvious: You drop the information that is least 'noticable' to the listener/viewer. But finding out what that information will be isn't a simple logical/mathematical problem in the way that lossless compression is: You need use a lot of empirical data to build a really detailed model of the human auditory and visual systems. (i.e. you have to do a lot of experiments with real human subjects) This takes a lot of time and costs a lot of money, and at the end, there's still a fair amount of guessing involved.
Um no. No amount of calculation is ever going to be able to remove artifacting from lossy to lossy transfers. And if you mean that we need to use more powerful calculations to make better lossless compression, that's not going to happen because you hit a theoretical limit. Every file has a theoretical limit to lossless compression, which represents the total amount of unique information in the file.
And also, if you were to, in a lossy codec, map out which bits were original, and which artifacts, so that you could transfer to another codec without doubling artifacting... well that information embedded in the file would add more size to it than you took out by compressing it, so what's the use in that?
And lastly, since compression's main goal is to minimize bandwidth, this whole arguement will probably be moot in ten or fifteen years anyway when next generation broadband really takes off.
thanks. by the way, if your username taking after the song by The Tubes of the same name? if so, cheers to you!
madamimadam
macrumors 65816
I wish I could say that that was the case.... just worked out once while I was pissed that it worked backwards and forwards and my name is Adam so.......