It is handy when I’m on a slow/mobile connection to be able to receive an MP3, do some edits and then send an edited project file back to whoever has the uncompressed files, who can then import those into a project file to create masters.
But I can convert the MP3 to a wav manually before importing to do that.
@tgoose - converting mp3 to wav will end up in unwanted artefacts no matter how good the algorithm that you use is. that is just what the originally post is saying.
cheers,
doc
@nowhiskey: I think what he meant was sending the .ardour project file to the one who has the uncompressed files.
ok, but i am not sure if ardour would think that the file ‘guitar.wav’ is the same as the file ‘guitar.mp3’ (or flac or what ever).
but yes, it should be possible to replace the files manually. but that could be a lot of tricky work.
i do not need to import mp3’s but exporting to that format would be good, when doing some test exports in the middle of a proces of mixing/mastering.
cheers,
doc
the C.L.A/nowhiskey.: Yeah, that is what I meant (although I wasn’t talking about Ardour specifically since I have not done it and I’m not aware of how it would be done, which is why my wording may have been a bit vague or misleading… sorry!). Just wanted to point out that there are some workflows where using MP3s can make things quicker without affecting the final audio quality.
I’m aware of the problems that can arise from using MP3s/lossily compressed files directly at any stage (although to be achingly precise, it’s not actually the conversion to WAV that causes artifacts).
regarding exchanging MP3/ogg, or even FLAC, as “quick and dirty” exchange format for tracks, one problem would be the scaling: Ardour uses floating-point WAV so there’s no “hard 0db” limit to how loud a track can be, or any sort of real “bit quantisaton danger” level.
So at least you’d have to normalise and bounce each segment of audio before compressing it.
It might be a nice thing to have automated with “Ardour Session Exchange”, as an option (not sure if ASE has been brought up to date with ardour3 or even ardour2).
It would remain “Quick&Dirty” even with FLAC since it would compromise quality because you have to convert to 16bit integer audio.
@Seb: According to Wikipedia FLAC can do from 4 to 32 bits, but only fixed- not floating-point. I’ve been using 24 bit FLAC myself.
Wavpack on the other hand can do 32 bit floating-point as well.
Regarding the usage of lossy formats: I’ve been working on a collaborative project where we exchanged our guiding tracks in a lossy format to keep the traffic and space on our server low. Only the final tracks would be uploaded in 24 bit lossless format.
So there is certainly some use for lossy formats, but personally I try to stick to a format wich is not patent encumbered, when possible.
@justyn: given that Ardour on OS X does, in fact, support the use of MP3 files as part of the editing & mixing workflow, I don’t think its much of a barrier. In fact, the existence of this article is probably now a bigger issue than anything technical. I don’t believe that Ardour’s lack of MP3 support on Linux represents much, if any, missing potential revenue, and whatever tiny amount it might be is over-ruled by the actual argument I presented above.
I understand what you’re saying, but I don’t agree with your approach. One point I feel you’re not taking seriously enough is that people may be used to using MP3 files - as you say, other tools support it. Or people may wish to work with their MP3 collection when they are just starting out.
The lack of support becomes an extra barrier that may help put them off trying out Ardour in the first place. They may instead choose another tool, and never become an Ardour user.
I think that you’ve got to ask yourself what is more important to you: getting Ardour in the hands of more users (and therefore, I might add, the chance of more development income) or educating people about lossy file formats in sound production. Deliberately avoiding supporting MP3 for reasons of principle has no benefit for Ardour, only potential downsides. And I would argue that even for the latter cause it would be better to get these errant users working with Ardour and educate them from within the program, rather than take any steps that will reduce the chance of them seeing Ardour in the first place.
Of course, when it’s a question of allocating precious development hours then that’s another matter (and of course it always is), and there is the licensing issue.
Anyway, it is your call and I respect your opinion, I hope you will not be offended by this comment.
Well, I think Paul is wize to stick to his principles - keeping a solid clean basis. As is clearly evidenced by some of the examples found in “Made with Ardour” , high quality sound can be attained using Ardour. That is a key point and a (the) raison d’ etre of Ardour.
I think processing (sampling) of MP3 files is mosly relevant within genres of music where noise is considered a quality in itself.
@timrob: if you start with lossily-compressed material, nothing you can to the audio will ever put back the data that is missing from the beginning. It doesn't matter whether the "final" output is wav, flac or some other format - if that file is ever reconverted to some other lossy format, the result is a total mess. You're not getting the benefit of 24 bit audio - the process you describe is totally independent of the bit depth you use.
I suspect he was referencing using the MP3 for timing purposes, and resubmitting an overdub back in full quality, in which case the quality of the MP3 is inconsequential as it isn’t mixed into the final output at all. I have done similar on other projects, and while I have no issue just decompressing the MP3 to import it into the timeline, it is one of the few valid arguments I could see.
Seablade@timrob: if you start with lossily-compressed material, nothing you can to the audio will ever put back the data that is missing from the beginning. It doesn’t matter whether the “final” output is wav, flac or some other format - if that file is ever reconverted to some other lossy format, the result is a total mess. You’re not getting the benefit of 24 bit audio - the process you describe is totally independent of the bit depth you use.
It is true that if libsndfile simply supported MP3’s then we wouldn’t be having most of this conversation. Instead, I get asked “why can’t I import MP3’s into Ardour?” by Linux users, and I proceed to explain why they should not do so even if they could. So, although licensing is the proximal cause for the situation on Linux, the core, key issue is that people should not be mixing in this way. Not with Ardour, not with Logic or any other DAW.
@jancsika: The problem with using lossy formats is that they permanently degrade the audio. Once a file has been compressed to a format such as MP3, sonic information has been lost forever and unwanted artifacts have been added which cannot be removed. So if you import an MP3 into a session, any file that is derived from it (and all generations that follow) will also suffer from that degraded sound. It doesn’t matter whether you output a lossy or lossless format, the permanent loss in quality already took place when the MP3 source was created.
I appreciate the dedication to quality audio, but to say that MP3 should never be used in the production process is ludicrous.
I get files from all over the world for overdubbing. Many of the people live in areas where they have low bandwidth. So they send sub mixes in MP3 format which I then convert and use in my overdub session. I send them back a Wav or FLAC file. The final product only relies on full 24bit audio for mixing. The process saves a bit of time and the production still gets the benefit of 24-bit audio.
While I don’t like compressed formats for distribution, there are plenty of justifications for using them in the production process.
I suspect that Ardour’s position on this is really a matter of licensing and not so much about quality.
Commitment to quality is a noble attribute, but placing arbitrary limits on the function of an application will limit the user base.
Best Wishes.
I think we are at the point of why ardor remains a niche project …
the reason is simply that you do not add those functions that serve the people.
Take reaper … because he had his success?
simply because it is a good cheap product and complete …
ardor is a bomb ready to explode but fails to do so … but for the simple fact of what it lacks.
I saw a post that a developer has proposed to add the function of markers “to cubase and ableton” and then coming to a daw full of features like the most famous …
then why can not take off?? Only because a user is not at ease, this tread is the ultimate example. because I can not use mp3 files if I need it or want it? As we begin to actually insert a function of conversion when importing mp3 files?
Only because all the best sequencer give you a form to its sound fonts and a parametric eq on the channel and ardor not?
the goodness of a sw not only to assess the goodness of his code (although the lack of bugs is a very important thing) but also the chance to follow your workflow, if I want to use the mp3 file and mix in a project files or other wave or mp3 files sampled from the base to create music that appeals to me, to you the development team that creates discomfort there?
I do not want an open flame, or what, I want you to think only on certain points, the development of a sw, even ardor, is itself a commercial activity, and a service that you offer to people, if people can not aprezzare your efforts, and I know you’ve had a hard pull of ardor, perhaps there is some trick to be taken to change opinions on the trend, it is better to have an economic upside.
The result obtained is that people change daw or operating system that educates people and helps them to use, most people use Linux for daily tasks, and window or mac to produce music, this should give an alarm bell, as things that I said we reaper.
guardaqueste things for people to choose and if you have two choices choose one where there is better, even if it means that shall violate licensing or other …
ardor is a great product in itself, but has many small changing to do to make it truly flourish, and some have mentioned here, like having your tools to work with sound, read the mp3 files, and tools to get full access to the potential of your hardware and your sw. no getting away from this, as you can not escape the fact that if there is a version of ardor that can attract customers is the version for osx and window in the future, and therefore get people to linux because if one is comfortable with here two systems that have more plugin compatibility of sound cards can rate it good instead of Linux that can run a serious card is a miracle.
I want to point out that some functions than in the magazines You must be a moment …
as they enter steps
I’m a Music Technology graduate.
I have compressed files to 128, 64, 32kbps .mp3 and even as low as 8kbps using .mp2, just in the name of using the results to educate other people about lossy compression.
I understand the processes involved in mp3 compression, and have even poked around the source code of multiple mp3 codecs, which means I probably understand the topic better than 99% of people.
I am fussy about my sound quality, and I understand the implications of using lossy file formats.
However, sometimes someone comes to me with a compressed file and says “Here’s the backing, let’s record.” Do I send them away and say “Find me an uncompressed file, and don’t even think about paying me for my services unless you have one.”? Of course I don’t.
I use something other than Ardour to convert to .wav, so that Ardour will accept the file.
It’s inconvenient.
It’s more work for me, and I’d rather Ardour would do it for me.
I’m not going to stop using Ardour because of it, but I deplore the idea that the feature is deliberately omited because it’s ‘The Wrong Thing’.
If I wanted programs that limited what I can do, I’d go back to Windows.
I thoroughly agree with what timrob says. Especially his opening and closing statements.
I’m not going to stop using Ardour because of it, but I deplore the idea that the feature is deliberately omited because it’s ‘The Wrong Thing’.
If I wanted programs that limited what I can do, I’d go back to Windows.
I thoroughly agree with what timrob says. Especially his opening and closing statements
Apart from the arguments for and against omitting a feature because it might encourage users to (knowingly or otherwise) do the “wrong thing”, in the case of mp3 there is an important patent / license issue. This is something that can’t simply be ignored just because its a little inconvenient - like them or loathe them, patents are very real and can cause significant cost / problems for a project.
Of course, one of the arguments often given in favour of open source is that if a feature is missing you can just add it yourself (which depending upon your level of skill may or may not be an option - its certainly “technically possible”, and in that case you can choose how to address any license / patent issues should you decide to distribute your changes)
@megamasha: Mp3s are not supported by libsndfile because the code to support them would carry with it an obnoxious licensing fee: http://www.mega-nerd.com/libsndfile/FAQ.html#Q020. In other words, they are the “Wrong Thing” because of the way a patent-encumbered de facto standard forces the developer to take on the burden of the whole legal mess surrounding the patent, licensing fees, etc.
IMHO FOSS is about choices. Limiting a user’s choices “for their own good” has serious implications. I’m completely on board with saying “mp3 licensing prevents us from distributing ardour with mp3 support”. Any other reason given is counter to FOSS, it’s philosophy and culture.
FOSS==choice. That’s the whole reason it exists.
If a developer of the wireless software wpa_supplicant said “I’m not going to support open access points in wpa_supplicant because they are insecure” there’d be a fork the next day or people would use iwconfig.
Of course with the way labels have their recordings mastered now, I’d be honestly surprised if you could tell the difference in the end result. Overblown mastering kind of wrecks any sound quality and fidelity you may have had in the source material no matter how pristine it was.
I think The Black Keys have it right. Write your songs and record them any way you want. If they are good songs it won’t matter how you record them. The only people “pristine sound quality” matters to are audiophiles and mix engineers. They won’t help you get airplay or sell sides. The average teenager or people that buy concert tickets don’t give any semblance of a crap. Your song either rocks or it doesn’t.
IMHO the lack of mp3 support simply means I hook up my ipod to an input and record it again. no one will care. Do I work that way if I don’t have to? Of course not.
I used to be a purist, been mix engineering since 1988, then I realized all that matters is getting the job done, having a good clock source, and keeping the hiss to a minimum if you have more than a few tracks you are mixing. Get your balances right, use a parametric right when you need to, and the world will turn. Where your source material came from or the format it was in are irrelevant as long as the end result works and the musicianship is good.
Yea I wince when I hear a 56k mp3, but I bet I’m the only person in the room that does.