Batch SSRC

[EpheMeroN]

Are there any tools to do batch encoding with SSRC?
I have 7 albums that I need to do sample conversions with and a batch method would greatly cut down on the manual work.

[johnman]

Wavewizard uses ssrc_hp to resample. Look at the forum for the latest release.

[EpheMeroN]

I installed your WaveWizard v0.43b just now. Are there any options I can tweak for using SSRC? Also, will you have support for ReplayGain soon?

[johnman]

I installed your WaveWizard v0.43b just now. Are there any options I can tweak for using SSRC? Also, will you have support for ReplayGain soon?

ww has allmost all options ssrc has (everything except --twopass), what do you need? Its not a frontend so you cant actualy change a command line if that was what you wanted.....

ReplayGain is not a big priority for me, but if the is a demand for it, i can always add it :rolleyes:

[ursamtl]

ww has allmost all options ssrc has (everything except --twopass), John is there a technical reason why you haven't included twopass? I use it all the time.

[johnman]

John is there a technical reason why you haven't included twopass? I use it all the time.

Im working on it now :)

[EpheMeroN]

Doesn't the -twopass option increase quality by avoiding clipping?

Also, I would love ReplayGain, as I have heard many times that it's much better than regular normalizing (don't know TOO much on the subject though).

[johnman]

Doesn't the -twopass option increase quality by avoiding clipping?

Well, thats partly true. If clipping didnt happen, its just a waste of time.

The new ww gives a message if clipping has occured, and in the list you can see which files clipped. I personally dont like it if programs do to much automaticaly. If clipping occured i would rather normalize it myself. But thats just me. I used to have this option (in an unreleased version) but since i didnt like it i also removed it again.


Also, I would love ReplayGain, as I have heard many times that it's much better than regular normalizing (don't know TOO much on the subject though).

well it might be better, but thats not always the case. I remember a thread on HA.org that described some problems when applying replaygain and then compressing it (to mpc IIRC). I dont know exactly what how or when, but it is not always a good idea to apply replaygain.

Im going to look into it, but if its to much work, il keep it on my todo for the next release. Currently im trying to support ac3encoding in cb, and when its finished, ill release a new ww.

[ursamtl]

Well, thats partly true. If clipping didnt happen, its just a waste of time.

The new ww gives a message if clipping has occured, and in the list you can see which files clipped. I personally dont like it if programs do to much automaticaly. John, I agree with you about some programs, but then again in this case if a file did clip, you'd have to redo it again so that's a waste of time too. Having the option to do twopass available would be good for those who don't care about the extra time (my experience has been that the second pass only takes a few extra seconds anyway).

Regards,
Steve.

[johnman]

What do you think is better, do a real two pass by first searching for the peak and then do the real conversion, or to do the second pass only when clipping is detected? Both are not to hard to do so..... its up to you :cool:

[ursamtl]

As I understand it, peaks that exceed 0dB may not be present in the source but can be produced by the conversion process. Therefore, searching for peaks before the conversion is pointless. Detecting peaks that exceed 0dB after conversion shouldn't be a problem as long as the data is in 32-bit floating point format.

[johnman]

As I understand it, peaks that exceed 0dB may not be present in the source but can be produced by the conversion process. Therefore, searching for peaks before the conversion is pointless. Detecting peaks that exceed 0dB after conversion shouldn't be a problem as long as the data is in 32-bit floating point format.

Sorry i wasnt clear enough...

What i was trying to explain are the following possiblities:

-- convert it witout saving it, and look if clipping occured. If clipping occured the the amplification will be lowered a little, and then reconvert it and save it for real. This way you dont have to save the first time which improves the speed a little

- same as before but with a large tempfile. This way the resampling doesnt have to be done again (if resampling was selected)

--or just convert AND save it, and if clipping occured do everything again.

[EpheMeroN]

I am quite new to understanding how audio conversions work, and just audio in general so maybe someone can help me figure this out a bit. I was under the assumption that the --twopass option in SSRC auto-detects clipping and corrects it yes? Like if it clips at a certain part in the audio file, during the second pass it will lower it automatically so it will not clip. Now, if I want to use SSRC to go from 44100hz to 48000hz 'AND' also normalize all the cd's won't that leave me with another possible chance of clipping during the normalizing process? I'm just trying to find the best method of handling this. Finally, can WaveWizard decode MP3s to WAVE? Up until now I was going to use CDex to give me the WAVE files to start out with. I once read on the HydrogenAudio Forums that CDex performed really really well at decoding mp3s to waves.

[daphy]

--or just convert AND save it, and if clipping occured do everything again.
for me this methode makes sense - if there is no clipping, no more further time will be wasted in a second pass :rolleyes:

BTW
maybe a mod could join this thread to the ww posting :goodpost:

[johnman]

I am quite new to understanding how audio conversions work, and just audio in general so maybe someone can help me figure this out a bit. I was under the assumption that the --twopass option in SSRC auto-detects clipping and corrects it yes? Like if it clips at a certain part in the audio file, during the second pass it will lower it automatically so it will not clip. Now, if I want to use SSRC to go from 44100hz to 48000hz 'AND' also normalize all the cd's won't that leave me with another possible chance of clipping during the normalizing process? I'm just trying to find the best method of handling this. Finally, can WaveWizard decode MP3s to WAVE? Up until now I was going to use CDex to give me the WAVE files to start out with. I once read on the HydrogenAudio Forums that CDex performed really really well at decoding mp3s to waves.

The clip detection is nothing more then finding the highest peak in the file and if its to high, lower the overall volume so that the peak is just below the max.

Normalising to i.e. 95% is finding the highest peak, and change the overall volume so that the highest peak is at 95% of the max. So if you normalise there shouldnt be any clipping anyway. And if you are thinking about normalising, i wouldnt go above 95% just to be on the safeside.

So if you normalise and resample at the same time in ww, there is never any clipping.

About the mp3-decoding, ww once had this option, but when i released it, i removed it again. Im not to sure about the licensing stuff. But it still accepts mpeg audio files since i forgot to disable that to :rolleyes:. So you can add them, but ww only creates an empty file when "converting" them.

Doesnt cdex use uses the mpg123 lib? That is indeed a good decoder for mp3 (ww used it to), but according to the author the decoding of mp1+2 is a bit shaky. The lame decoder is also based on mpg123.

[ursamtl]

For decoding mp3's I highly recommend dBpowerAMP Music Converter (dMC). I've been using it for awhile and it works extremely well. You just right click on files and choose Convert then configure the options. It's free (there's an mp3 encoder that's trialware but decoding is free. dMC handles flac, ape and a whole variety of formats. Check it out at http://www.dbpoweramp.com/dmc.htm.

[ursamtl]

The clip detection is nothing more then finding the highest peak in the file and if its to high, lower the overall volume so that the peak is just below the max.

Normalising to i.e. 95% is finding the highest peak, and change the overall volume so that the highest peak is at 95% of the max. So if you normalise there shouldnt be any clipping anyway. And if you are thinking about normalising, i wouldnt go above 95% just to be on the safeside.

So if you normalise and resample at the same time in ww, there is never any clipping.



As I understand it, the second pass is something like a forced normalization in that it checks for peaks that go over 0dB as a result of the conversion process and if it finds one then the whole file is attenuated so that the peaks fall just below 0dB. So, perhaps you're right, normalizing will take care of clipping, as long as it occurs after the conversion. On the other hand, if there's no clipping, the data is not affected when normalizing is not automatic. I have read some comments by pro audio folks who advise people never to normalize.

[johnman]

for me this methode makes sense - if there is no clipping, no more further time will be wasted in a second pass :rolleyes:


Since the votes were 1 vs 0 vs 0 in favour for the reconversion when clipping is detected, i used this method :)

[ursamtl]

Er, well actually I voted for SSRC's twopass method as it is used in the program. I guess I just didn't say it clearly enough to be perceived as a vote. :) Ah well...

Is there any way you could at least put in a checkbox for those who want to use it the original way?

[johnman]

Er, well actually I voted for SSRC's twopass method as it is used in the program. I guess I just didn't say it clearly enough to be perceived as a vote. :) Ah well...

Is there any way you could at least put in a checkbox for those who want to use it the original way?

i just understanded that you want somekind of twopass, never you want the ssrc way. Well vote is not over untill the release so... now its 1v1v0.

Sure i can add it, but do you expect all files to clip? I mean if one in 10 files clip its faster to redo a single file then to do twopass on all of them. But ill add an extra radio button anyway :).

EDIT I just looked at it, and although its easy to do on normal file conversions, the "ssrc method" gives a little problem when merging files. So im afraid i have to push this to the next release since im trying to realease a new version asap. (hopefully today :) )

[ursamtl]

Actually my experience with twopass has been that it adds only a second or two processing time to files without clipping. This seems to be the clipping detection time. So if you're going to implement clipping detection and then redo the whole conversion, it would actually be faster to let ssrc handle it. As I understand it, the way twopass works is that the data is stored in a temporary buffer while clipping detection takes place. If clipping is detected, then ssrc attenuates the temp data level until the peaks fall below 0dB and then writes the file; if no clipping occurs, it just writes the file. That would make more sense than redoing the complete conversion because if you did redo it, some clipping is the result of the conversion itself so you still have to run the clip detection after the conversion anyway!

Regards,
Steve.

[johnman]

Actually my experience with twopass has been that it adds only a second or two processing time to files without clipping. This seems to be the clipping detection time. So if you're going to implement clipping detection and then redo the whole conversion, it would actually be faster to let ssrc handle it. As I understand it, the way twopass works is that the data is stored in a temporary buffer while clipping detection takes place. If clipping is detected, then ssrc attenuates the temp data level until the peaks fall below 0dB and then writes the file; if no clipping occurs, it just writes the file.

Regards,
Steve.

IIRC ssrc's twopass makes a tempfile in the first pass which contains the output in a high resolution.

In the second pass the higher resolution tempfile gets converted to the final format, and if needed, attenuated to prevent clipping. This way the file gets resampled only once. So what you described is correct. It can indeed be a lot faster, but it also needs a large tempfile. So the actual speedup depends on the system. But i agree, this could be usefull, and ill add it soon. On my computer the speedup from doing a resampling twice, or working with a tempfile is about 95% because its very cpu intensive.

:goodpost:



That would make more sense than redoing the complete conversion because if you did redo it, some clipping is the result of the conversion itself so you still have to run the clip detection after the conversion anyway!

I dont understand this, ww detects clipping just before it converts the floating point samples to the final sample format. So it will detect the clipping always. And if the file is then reconverted, it will reconvert it exactly the same as before (even the dithering is identical).

Remember, not all conversions include resampling, so if you are doing some channelmapping (with mixing) on a fast computer, it might be the hardisk that is slowing down the conversion and not the cpu. When the cpu is not the limiting factor, it doesnt help to create a large tempfile. So imo both funtions are usefull, depending on whats the limiting factor (HD/CPU).

[daphy]

IIRC ssrc's twopass makes a tempfile in the first pass which contains the output in a high resolution.
this means you need a lot of space - John is it possible then to add a option to chose the location of a temp folder (many user suffer on less space on their system drive :scared: )

THX :)

[johnman]

this means you need a lot of space - John is it possible then to add a option to chose the location of a temp folder (many user suffer on less space on their system drive :scared: )

THX :)

Well, i was thinking to use the output dir for the file. Then the user has full control to which dir the tempfile is written to, and i dont need to add extra config options :).

This is btw one of the harderst thing to program so far :rolleyes: . Im trying to add this feature without doing to much hacking arround, but everything i tried so far ended in really ugly code .The option to map channels really makes everything a little complicated.

[ursamtl]

By the way, John, you do know that the source code for ssrc is available, right? I assumed you're working with it, but I thought I'd mention it in case you aren't.

[johnman]

By the way, John, you do know that the source code for ssrc is available, right? I assumed you're working with it, but I thought I'd mention it in case you aren't.

Yeah i know, its where the ssrc.dll from ww is based on. The problem with doing twopasses in ww isnt the twopasses, its my program architecture which makes it difficult.

EDIT i found a solution to the problem, and it wasnt even that difficult :). It took only 30 lines of code. I knew it should be possible to do two passes without to much trouble. But i got a little lost in my 8k+ lines of code (all in a single file).

So tomorow ill implement it "for real", so v0.5 of ww will also have a twopass method :cool: .