On Sun, 20 Mar 2016 21:59:07 +0000 Fons Adriaensen <fons(a)linuxaudio.org> wrote: OK, thanks. What's the difference between this 'normalisation' and a heavy compressor ? Still, this brings a practical question: how to integrate tranquil pieces in a list, say, as on a CD, without having the listener going to the volume knob and, while still keeping intact the breathing room of the soft pieces in comparison of the loudest ones in the same set ? Cheers.

On Sun, Mar 20, 2016 at 06:28:20PM -0400, jonetsu(a)teksavvy.com wrote: The normalisation will not really modify the mix or the dynamics. It just adds some gain so the level is the maximum that the export file format can handle without clipping. In other words, it should sound just the same after you adjust (reduce) the volume. Now if playing back the normalised file results in clipping or distortion, that means that either your sound card can't handle full digital level, or you have too much gain after the soundcard. If the CD has both pieces that should be loud and others like yours that are meant to be softer, then you did the right thing. But it all depends on what the listener wants - many will want a constant level regardless of any artistic intentions. Your track has quite a low level, even if it is intended to be soft. Ebumeter says the loudness is -3.7 LU. That's relative to an already low referenc value of -23 dB. Still that's probably OK iff any other tracks it is bundled with are also mixed to a well defined loudness instead of maximum peak level. It's a real shame that Ardour only offers peak normalisation. Peak level has no perceptual meaning at all, there is really no reason why a mix should ever be peak-normalised. All the code required for real loudness normalisation is already there, so it would be trivially simple to offer that as well. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On 03/21/2016 10:00 PM, Fons Adriaensen wrote: Except for some medium related cases, most of them historical. Great. trivially simple cases are those which are best left as exercise to the reader, right? :) There are plans to adding loundness normalization to Ardour. The first step was to add analysis (new in 3.7: https://ardour.org/images/post-export-analysis-4.7.png - BTW, under the hood this was implemented as re-usable VAMP plugin and is not limited to Ardour). Recent Ardour git versions also allows to analyze regions and ranges. This information can be already be used to apply some gain factor manually but currently cannot be automated. To automate it, we need a couple of config-settings in the Export Format Dialog, save/load the state and ensure backwards compatibility. Then do the same for region-gain and finally test it all. That'll keep someone buy for a week or three. If you want it all and now,.. well you know where to find the source-code. Cheers! robin

On 03/23/2016 10:40 PM, Fons Adriaensen wrote: Well, one can argue over style all day.. The unwritten rule is to follow the coding style of the project that one contributes to (if you like that style or not). But if you have to change the style please keep it separate: Pretty much all FLOSS projects out there (and I imagine most proprietary projects too) separates NO-OP whitespace changes from actual code changes and most of them refuse to merge changes that mix both in a single commit or patch to some degree. That helps a lot to review code changes. ciao, robin

On Wed, March 23, 2016 5:40 pm, Fons Adriaensen wrote: Paul applied this patch recently in preparation for a new jack1 release: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-Februa… There seems to be a regression related to the changes. http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-March/… I am sure the developers would appreciate debugging help. -- Chris Caudle

On 24.03.2016 13:02, jonetsu(a)teksavvy.com wrote: There is no 'THE JACK', JACK1 and JACK2 are equivalent implementations of the same API with slightly different feature sets. People choose the one that suits their needs. More info here: http://www.jackaudio.org/faq/jack12n.html

On Thu, 24 Mar 2016 08:46:53 -0400, jonetsu(a)teksavvy.com wrote: I don't think so, Debian/Ubuntu already preferred jack2 over jack1 before pulseaudio and Linux Mint simply is a Debian/Ubuntu derivative.

On Thu, 24 Mar 2016 08:02:46 -0400, jonetsu(a)teksavvy.com wrote: On Debian/Ubuntu applications such as Ardour have a dependency to the the package "jackd" and the package "jackd" requires to install the package "jackd1" or "jackd2". "jackd1" is older than "jackd2", so it's nothing new. Here is an overview of the differences between jack1 and jack2: https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_j… News about latest innovations and development status could be find by recent posts to http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org , unfortunately reading the archive requires to subscribe. For jack1 it starts here: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-Januar… For jack2 it starts here: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-March/… It's important to read the follow-ups to avoid misunderstandings, especially about the future of jack1. The reason for several jack2 users likely is this one: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-Februa… One reason why I'm using jack2: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-Februa… However, regarding this issue I likely likely could use jack1 too: http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2016-Februa… Regards, Ralf

On Thu, 24 Mar 2016 07:28:58 -0700 (PDT) Len Ovens <len(a)ovenwerks.net> wrote: I am not so sure that this relates strictly to jackd... I certainly like the capability of routing any ports to any other using qjackctl. Recently I have found out that Renoise for instance can create any number of output ports. So if there are 12 tracks in Renoise, it is possible to map these tracks individually to Ardour for mixdown and further processing. I do not know if the same flexibility would be available when running ALSA only.

On Thu, 24 Mar 2016, Will Godfrey wrote: I agree. The comments I am looking for are as to how much interest there is for actually maintaining and improving jackd (1 or 2) in the development community. No matter how useful a project is, if it is not kept up, it will die. All of the stuff I have set up personally use jackd2. But I have looked at what I do and could use jackd1 comfortably as well (even with pulse audio and no patches). There are a lot of projects and groups of projects that depend on jackd and I want to see at least some version "make it". Personally, I would like to see a version of jackd that can replace pulseaudio OOTB. I only use PA as a front end for jack right now as it is, but integration would be better. It would allow for things like skype needing longer latency than 256/2. That is jacksouce/sink should add it's own buffering. I would like to see a Jackd3 that truely replaces both jackd1 and jackd2 in a way that no one really has reason to keep using them. Unfortunately, my DSP coding is such that for me to try to develop a jack3 would just make sure that people kept using jack1/2 :P Right now, PA with jackdbus as a backend is my personal sweet spot for all around use. (means - can be set up on my wifes computer and I can walk away) -- Len Ovens www.ovenwerks.net

On 24.03.2016 21:24, Fons Adriaensen wrote: With all due respect... please send a proper patch next time. This is something I'd love to try too, I even attempted to start cleaning up the patch myself too but then Paul said he would do it.. If the patch was good from the get-go we wouldn't be having this discussion.

(1) I explained to Fons in person and to everyon on the jack-devel mailing list what the issues with Fons' original patch. Robin Gareus has eloquently restated the basic point, but I'll do it again: the ability to REVIEW code changes is critical to long-lived projects, and when a change consists of 85% or more white-space/code style changes and only 15% actual functional differences, code review becomes all but impossible. I would like to bequeath future JACK1 maintainers the ability to go back and understand the changes from Fons, but that is absurdly hard to do when so much of the commit would be absolutely irrelevant. (2) I also documented my process for attempting to test Fons' changes. To repeat: (1) copy the entire code tree, twice (2) clean up the first copy with uncrustify, which implies a canonical coding style throughout. test this version for several days to identify any obvious regressions from what should be a no-op. (3) apply fons' patches to the second copy (4) run uncrustify on the result, which makes it similarly canonical in terms of coding style. (5) generate a diff between the two copies which theoretically should show only the functional differences introduced by fons (6) apply the diff and commit (7) test Initially, things seemed to go well during test (otherwise I would not have pushed). But over a period of a couple of weeks, which in my case typically involves running Ardour endless times a day, often crashing it, while other clients run along in the background, I got the distinct impression that the server was no longer stable in the face of misbehaving clients. I did a git bisect, as did others, and we confirmed that commit that occured at step (6) above was responsible. I then reverted that commit (visible on jack-devel). There are many other important changes in jack1 git that need to be released. Unless someone can identify what is wrong with the reverted commit, it will remain reverted, and I will release 0.125 without it (and then depart for post-JACK-ness nirvana). --p On Thu, Mar 24, 2016 at 5:04 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:

On Tue, Mar 29, 2016 at 11:12:21AM -0400, Paul Davis wrote: 1. All the places where the actual code was changed were clearly identified by comments. 2. When I compare the commit (42393121) that applied my patch with previous versions, there are *lots of* major coding style and whitespace changes in files that I never touched. This means the coding style wasn't consistent to start with. 3. When I read that same commit (which I assume reflects the preferred style) I see things like this: engine.c, line 3884: ----- if (dstport->connections && !dstport->shared->has_mixdown) { jack_port_type_info_t *port_type = jack_port_type_info (engine, dstport); jack_error ("cannot make multiple connections to a port of" " type [%s]", port_type->type_name); return -1; } connection = (jack_connection_internal_t*) malloc (sizeof(jack_connection_internal_t)); connection->source = srcport; connection->destination = dstport; connection->srcclient = srcclient; connection->dstclient = dstclient; src_id = srcport->shared->id; dst_id = dstport->shared->id; jack_lock_graph (engine); if (dstclient->control->type == ClientDriver) { /* Ignore output connections to drivers for purposes of sorting. Drivers are executed first in the sort order anyway, and we don't want to treat graphs such as driver -> client -> driver as containing feedback */ VERBOSE (engine, "connect %s and %s (output)", srcport->shared->name, dstport->shared->name); } else if (srcclient != dstclient) { jack_feedcounts_t *F; int dir = 0; if ((F = depends_direct (srcclient, dstclient)) != 0) { /* We already have a direct dependency, just increment the connection count. */ F->fwd_count++; dir = 1; } else if ((F = depends_direct (dstclient, srcclient)) != 0) { /* We already have a reverse direct dependency, just increment the reverse connection count. */ F->rev_count++; dir = -1; ---- If this is your idea of indentation that is supposed to help understand the code structure, then I'm lost. This sort of thing is why I modify whitespace when working on a file, just to be sure I have the correct idea of where conditionals and loops start and end. The original code was full of random indentation like this. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Wed, Mar 30, 2016 at 03:47:08PM -0400, Gene Heskett wrote: Normally I do. But this was 1) something I needed, and 2) a challenge. They are there, somewhere.... Another example. This is what I wrote (a new function): ---------- /* Delete a direct dependency of client B on client A. */ static void rem_depends (jack_client_internal_t *A, jack_client_internal_t *B) { jack_feedcounts_t *X, *Y; for (X = 0, Y = A->feedlist; Y; X = Y, Y = Y->next) { if (Y->client == B) { if (X) X->next = Y->next; else A->feedlist = Y->next; B->depcount--; free (Y); return; } } } ---------- And this is what was committed: ---------- /* Delete a direct dependency of client B on client A. */ static void rem_depends (jack_client_internal_t *A, jack_client_internal_t *B) { jack_feedcounts_t *X, *Y; for (X = 0, Y = A->feedlist; Y; X = Y, Y = Y->next) { if (Y->client == B) { if (X) { X->next = Y->next; } else { A->feedlist = Y->next; } B->depcount--; free (Y); return; } } } ---------- Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Wed, Mar 30, 2016 at 10:29:05PM +0100, Will Godfrey wrote: Jack's code apparently uses tabs (of 8 char) and that's why I did the same; normally I don't, and I use a 4 char indent. (for this and the previous post I 'untabified' the code.) AFAIK, placing a { at the end of a line is something from the times when each byte would cost half a dollar. But I can live with that. But not with indentation that completely obfuscates code structure. I had good reason to modify the layout of the code where I did that, it was a mess to start with. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On 03/30/2016 11:40 PM, Fons Adriaensen wrote: I recently learned to use it to indicate functions or scopes (curly on newline) vs branches. /^\t*{$/ matches declarations. But to each his own. How is mixing whitespace and actual code-change in a single patch not exactly the same kind of of obfuscation and mess? The diff is just as unreadable as the source that was criticized for being unreadable. ffmpeg for example drives a very hard line: not even a single no-op or whitespace change must ever coincide with an actual code or functional change. Personally I think that's a bit unreasonable, but it does make a lot of sense for huge projects with countless contributors and a only a small team to review each and every change. 2c, robin

Nobody is denying that your adding topological sort was a significant (and valuable) piece of work. Nobody is denying that there were inconsistencies in the coding style beforehand. Nobody is denying that there isn't much in the way of comments to document how things are supposed to work. The issue was how to (a) not make things actually worse (by making the coding style even more inconsistent) and (b) how to improve readability of the commit, since although it is almost certainly true that reading the diff alone won't convey the topo sort design, reading the diff *is* critical is anyone ever needs or wants to understand the *change* that was made. A secondary issue has been your continued insistence that submitting a patch formatted in this way is obviously perfectly OK. I have no idea how you would contribute to a project with (a) stricter coding standards and (b) a coding style that you didn't like. The project NEEDS your topo sort changes. The project cannot AFFORD the patch as it was presented. On Thu, Mar 31, 2016 at 3:00 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:

On 01.04.2016 06:48, Rick Green wrote: That's exactly what Paul did.

On Wed, Mar 30, 2016 at 10:29 PM, Gene Heskett <gheskett(a)wdtv.com> wrote: How about instead of getting your coat, you read the uncrustify config code (and the rest of this thread), and you help figure out how to make what uncrustify did better? Alternatively, how about you cleanup Fons' patch so that it doesn't consist of 80% meaningless code reformatting and is actual something that a future developer could read and understand what was changed without ploughing through dozens of brace repositionings?

On 31.03.2016 09:27, Gene Heskett wrote: This is what uncrustify was supposed to solve. By applying uncrustify on the original jack1 code plus the code with Fons' patch (and then generating a diff), we would, in theory, get rid of all the whitespace and style changes.. Either the uncrustify config is not 100% correct, or uncrustify itself has issues. In my opinion we should get back to the original jack1 code before uncrustify messed up things. And then try to generate a clean patch. I'm willing to do the clean patch if Paul reverts uncrustify changes. @Paul: is that ok?

On Thu, Mar 31, 2016 at 11:30 AM, Markus Seeber < markus.seeber(a)spectralbird.de&gt; wrote: I tested them myself for a couple of days, and they are present in the github repo, which has been used by several people to build and test jack1. My original plan was to compare the .o files generated before and after uncrustify, but I realized that this is not so simple.

On Wed, Mar 30, 2016 at 3:31 PM, Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: That is of close to ZERO help to someone who is trying to read a large commit and understand what was changed. I have no idea why you keep pushing this point. It is simply an utterly accepted feature of every open source project that involves distributed developers that you do not change the whitespace/indent/coding style, no matter how much you dislike it. I've worked on projects that would have just rejected your entire patch based on this aspect alone. I mentioned this to you in private. Instead, I took time to investigate code formatters, identify which one would likely do the right thing, and come up with a strategy for creating a commit that only changed what actually mattered. Nobody is questioning this. That is why my process for dealing with your patch FIRST involved using uncrustify to canonicalize the coding style. Normally I would not have bothered to do this, since it created a huge commit that in theory is a 100% no-op, and wasn't addressing any actual reported problem or issue. But it was the only way I could see to convert your patch into an acceptable format. This particular step would have been unnecessary without all the extra changes in the original patch. It reflects the work of uncrustify. I have attached the config file that I used. I am entirely happy to consider revisions to the uncrustify config file and we can re-run the canonicalization step. I'm entirely open to the idea that I didn't get the uncrustify config correct, and that there are better options to be used in order to achieve the desired result. I'm happy to take suggestions on how to improve this. Let me re-describe the scenario that we're discussing here: I received a valuable but terribly formatted patch that changed large amounts of code for no reason at all. Rather than reject it, I mentioned this to its author, who basically shrugged and said "it is what is is, this is how i work", completely ignoring convention in distributed development. I spent time to come up with a strategy for generating a clean(er) version of the patch, which either because of errors in the process or errors in the original patch, caused a regression in server stability in the face of less-than-well-behaved clients. After some discussion on jack-devel, I reverted the commit. At this point, the pushback I am getting is leading me towards simply rejecting the work out of hand and forgetting about it. The change/fix is an important one, and I want to see it included in jack1's codebase. But I will not put up with this BS attitude toward a problem that started when Fons chose to ignore conventional behaviour and believed that submitting a patch which was 80%+ reformatting changes was an acceptable strategy.

On Thu, 24 Mar 2016 09:13:10 -0400, jonetsu(a)teksavvy.com wrote: No, normalization is an optional feature, by default a mix is exported as is.

On Thu, 24 Mar 2016 09:53:46 -0400, jonetsu(a)teksavvy.com wrote: To export the master mix, it likely is wanted by many users that normalisation is applied by default, but it unlikely is a good idea when exporting individual tracks, to make this the default. Regards, Ralf OT: On Thu, 24 Mar 2016 10:12:18 -0400, jonetsu(a)teksavvy.com wrote: Said by people who are even unable to serve beer in appropriate beer glasses? "The glasses used for Kölsch differ a great deal from other German beer glasses, as they are of a cylinder form and only incorporate 0.2 liters. They are called Stange (de), which translates to bar or rod. This type of glass is owed to the fact that Kölsch gets flat quicker than other beers losing its white crest very quickly, too." - https://en.wikipedia.org/wiki/K%C3%B6lsch_%28beer%29

On Thu, 24 Mar 2016, jonetsu(a)teksavvy.com wrote: Looking at the 1010LT manual, I see that the jumpers are only for the two XLR connectors to set them Mic (-50ish) or line (+4). The manual then say that the i/o level can be set in the control panel (windows/OSx) to line, consumer or -10... that is +4, -4 or -10. I see that mudita24 does not have these settings and so would assume 0db = +4db out... which is definately too much for anything that likes to connect to the RCA jacks the LT comes with. You should probably be running your DAC levels at -12 or -14 if you are using -10 amplification for monitoring. -- Len Ovens www.ovenwerks.net

On Thu, 24 Mar 2016 12:32:07 -0400, jonetsu(a)teksavvy.com wrote: No, it's +4dBu vs -10dBV for the analog domain. ^ ^ ^^^^^^^^^^^^^ ^ ^ ^^^^^^^^^^^^^

On Thu, 24 Mar 2016 10:29:51 -0700 (PDT), Len Ovens wrote: No, it's less than -12. -10dBV is < -7.8dBu +4dBu is < +1.8dBV 4 + 7.8 = 11.8 10 + 1.8 = 11.8

On Thu, 24 Mar 2016 19:18:57 +0100, Ralf Mardorf wrote: Not my day today, this would be a similar mistake as 4 + 10 = 14 ;). It's around 11.8 :).

On Thu, 24 Mar 2016 11:25:40 -0700 (PDT), Len Ovens wrote: It's most likely 11.8, but what does it mean for the dBFS? https://en.wikipedia.org/wiki/DBFS#Analog_levels : EBU R68 is used in most European countries, specifying +18 dBu at 0 dBFS In Europe, the EBU recommend that -18 dBFS equates to the Alignment Level European & UK calibration for Post & Film is −18 dBFS = 0 VU UK broadcasters, Alignment Level is taken as 0 dBu (PPM4 or -4VU) US installations use +24 dBu for 0 dBFS American and Australian Post: −20 dBFS = 0 VU = +4 dBu The American SMPTE standard defines -20 dBFS as the Alignment Level In Japan, France and some other countries, converters may be calibrated for +22 dBu at 0 dBFS. BBC spec: −18 dBFS = PPM "4" = 0 dBu German ARD & studio PPM +6 dBu = −10 (−9) dBFS. +16 (+15)dBu = 0 dBFS. No VU. Belgium VRT: 0dB (VRT Ref.) = +6dBu ; -9dBFS = 0dB (VRT Ref.) ; 0dBFS = +15dBu.

On Sun, 20 Mar 2016 16:19:30 -0600 S D &lt;stephen.doonan(a)gmail.com&gt; wrote: Yes, will certainly do. This was a little jam that happened when trying out for the first time two mics to record the acoustic instruments. There are so many of these. Just the last few days, about 5 or 6 happened, of which I posted one today that I polished a bit, providing enough base material for the next months. Interesting. I'll be happy to hear it. Cheers.

Check also Ian Shepherd's blog: http://productionadvice.co.uk/blog/. It's full of good advices and analyses about mastering and loudness war. Bob Katz's book is also excellent, a must-have I'd say. -- Emanuele Rusconi

On Sun, 10 Apr 2016 22:05:30 -0500 "Chris Caudle" &lt;chris(a)chriscaudle.org&gt; wrote: Thanks for the links. Bob Katz's article questions the use of normalization. I have made a 'non-norm' setting in Ardour for exporting now. It is not obvious that after so much time spent on a piece adjusting sometimes up to 25 tracks, that all is thrown to a mathematical function that will modify levels. So I use 'non-norm' now and wonder why normalization is a default in Ardour/Mixbus. This is the second time I see this method mentioned. I might try it later on this year. Thing is, I never do that when listening to CDs in a noiseless environment (eg. in the car some tunes might be too soft, needing volume compensation). The softer tune will come across as fine as the dynamic one before. Or will at least give the impression. Within a single CD 'universe' there should be some kind of 'level' consistency independent of the dynamics of the pieces. I've only very recently started to load in Ardour some commercial pieces and see how they fare, with the help of some meters that can give reference numbers for a beginner, between themselves, and also compared to mixes I have done. To follow a bit Harrison's 'Gain Staging' video, the very first thing is to have waveforms that are in the same range. https://www.youtube.com/watch?v=uHEUKKvVtCg The level the VU meter is adjusted at also influences the results (didn't knew about that).

On Tue, Apr 12, 2016 at 4:58 AM, Thorsten Wilms &lt;self(a)thorstenwilms.com&gt; wrote:

On Tue, 12 Apr 2016 10:58:10 +0200 Thorsten Wilms &lt;self(a)thorstenwilms.com&gt; wrote: I'd say I have an idea in the ballpark of what it does, as Robin explained it here, for one. So above it says: "making it equivalent to nudging the master gain fader." That's it. Why would 3 weeks of work on 25 tracks be thrown to a mathematical function that will move one fader ? This is one thing that's tackled in Ian Shepperd's home mastering class, which is very interesting and, actually has me do the exercises and pay more attention to what is going on. Some people need that. Others go forward by themselves. It varies. I go forward in other domains. The idea with learning about mastering is to 'start at the finish' perspective to question the mixes, by learning about what is needed as approaches to a finish product. Some people start at the beginning... Looking forward for this. BTW, Robin's spectrum analyzer is quite something when it comes to correlating audio events to frequencies. The use of bar graphs distributed over the frequencies (scales ?) makes it less muddy. And the speed response adjustment is great. I have seen the voxengo span in many examples, tried to run it in wine, I have used Calf's and OvertoneDSP AF210 and they are more muddy, not as easy. So far I take that if it sounds like many commercial productions, then it is in the whereabouts of being OK, notwithstanding listening in the car, on the Behritone, cheap headphones.

On 04/12/2016 02:25 PM, Jörn Nettingsmeier wrote: It is equivalent to the guy who listens to the music turning the volume dial on the amp. It does not affect the mix at all. If you export too soft, s/he will have to turn up the amp. One positive side effect of normalization is that you get the best signal/noise ratio for the exported target (usually 16bit). If the loudest peak is at 0dBFS the whole [16bit] range is available for dynamic range. If the digital peak is at -6dBFS you get one less bit dynamic range (with integer encoding). ciao, robin

On Tue, Apr 12, 2016 at 9:56 AM, jonetsu &lt;jonetsu(a)teksavvy.com&gt; wrote: Imagine you just obtained a finished, commercially produced and mastered song. You play it on your music system with the volume set at 5.0. It sounds a bit too quiet, so you turn it up to 7.0. Did you change the mix? Did you change any aspect of the production process? Hopefully it is clear that you did not. Normalization is *EXACTLY* equivalent to this process.

On Tue, Apr 12, 2016 at 10:07 AM, jonetsu &lt;jonetsu(a)teksavvy.com&gt; wrote: the reasons have already been explained. primarily dynamic range: the ONLY downside of normalization is when it is done naively in ways that lead to inter-sample clipping during D-A conversion. As long as this is avoided (and it is easily avoided), there are simply no downsides.

Am 12.04.2016 um 15:56 schrieb jonetsu: I think you're still confused, but about another matter, which is level vs loudness. Commercial recordings all have their loudness enhanced by various means, so they sound louder, even if their peak level is the same. Normalizing is only about getting the peak level to some fixed value (e.g. 0dbFS). Chris

      Something is affected nevertheless.   I think I mentioned that.  Not just now, but earlier.  Comparing with commercial tracks of the same genre.  This is what I started doing.  First steps.  Much later on, developing a uniform experience from a series of original pieces.  I still do not see why I would throw anything at a 'mathematical function' at this stage of learning.  I might stick with that for a long time (there's at least one 'big guy', Bob Katz, that does not consider normalization in a good light, as can be read in a recent link posted here, so it might not be a uniform accord).  For now I much prefer to do all by craftiness, by observation and experiment and that all and every changes are made explicitly.

On 04/12/2016 04:04 PM, jonetsu wrote: Sorry, I'm dropping out here. If I didn't know your posting history, which is overall very constructive (if confused at times), I would assume you're trolling. Bob is arguing against the practice of normalizing every track as it comes in without thinking. There are also very good arguments against peak normalizing a master, namely that we should adjust for loudness, not peak level. Another of his arguments is the accumulation of rounding error in fixed-wordlength systems, which is very valid. But honestly, your understanding of the whole matter seems to be several tens of dBs away from the point where this becomes relevant. Unless you are willing to understand that normalizing the sum does not change anything in your mix, continuing this discussion is pointless. You should also get rid of mysteries and magical thinking, because half of the audio industry is drooling and waiting for non-analytical thinkers to show up so they can be ripped off, ruthlessly. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net

On 04/12/2016 04:52 PM, Paul Davis wrote: never call me that again, or i'll start posting improved summing algorithms to ardour-dev :) -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net

On Tue, 12 Apr 2016 16:39:05 +0200, Jörn Nettingsmeier wrote: Unlikely it often affects the recording in an audible way. However, I wouldn't care that much about normalization as the OP does, with or without, the loudest peak of all tracks should be relatively close to 0 dBFS, but it doesn't matter if it's a few x.0 dBFS below 0. Dithering is a much more delicate subject ;).