Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [split] Help with long files (over 8 hours) using exhale encoder (Read 6612 times) previous topic - next topic - Topic derived from exhale - Open Source ...
0 Members and 1 Guest are viewing this topic.

[split] Help with long files (over 8 hours) using exhale encoder

Ffmpeg.exe can't directly record to exhale, and I am reading only wav is accepted for the exhale.exe input.  (My searching says author thought the overpriced Main Concept ffmpeg plugin obviated the need.  But I can't justify taking $80 of my family money for the plugin.)

Since, I record speech, target <24kps, for 8 hours, to up to 130 hour sessions, several times a week, wav recording is going to thrash and kill my hard drive--I would think.

(I record, track split, wput upload using a dos bat files, so that I can more easily get the files on my phones, from home or in the field.)

Foobar converting with exhale, really isn't a practical option--although, it seems to work well. At least, not in the long run, where command line bat files work best.

So, really, either I need the ability to input some other compressed format into exhale.exe, without the wav step, or a way to ffmpeg record into exhale--I think.


Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #1
Try piping wav output from ffmpeg to exhale.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #2
Try piping wav output from ffmpeg to exhale.

After about 3 hours of reading on how to pipe to Exhale.exe, I am more confused than ever.

To my mind, the most credible dos line would be, on my machine:  ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -t 17 -c:a pcm_24le -f wav pipe:1 | exhale.exe pipe:0 Output.m4a

Exhale just complains as follows:  av_interleaved_write_frame(): Invalid argumentpeed=N/A
Error muxing a packet for output file #0
Error writing trailer of pipe:1: Invalid argument

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #3
     :The most logical dos line:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -t 17 -f wav -vcodec rawvideo -acodec pcm_s16le pipe:1 | exhale.exe pipe:0 Output.m4a
        :Didn’t work.

 This kind of works, and creates a temp file called s:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -t 17 -ac 1 -ar 22050 -f wav -vcodec rawvideo -acodec pcm_s16le %s|exhale.exe b %s Output.m4a
     : But the reason it doesn’t work is that the -t and other arguments like -ar and -ac are ignored, as are any bit rate arguments in exhale

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #4
I have been doing more listening tests, and I love Exhale even more.   I think it is essential for speech recordings to avoid <24kps Opus peak grain--the subtle, but ever present, chest hiss of Opus that makes me think the speakers have terminal pneumonia at an acceptable <24kps file size.

This dos sound card to Exhale line, works, but only yields an unusably unnecessarily large file, for speech:  117 kps exhale m4a!:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -t 17 -ac 1 -f wav -vcodec rawvideo -acodec pcm_s16le %s | exhale.exe b /i %s Output6.m4a              :(I don't know about the /i, just tried it after 9 hours of googling and reading)

I am not sure if the line's Exhale argument of b quality is being used or not by exhale.exe. I doubt it. If so, then exhale.exe simply needs to be rewritten for a lower bit rate on stereo piped un resampled wav files, since mix to one channel isn’t possible in this hypothesis. Else exhale needs to be able to accept, as valid input, the -i audio="CABLE Output (VB-Audio Virtual Cable)"  as it does a wav (but it would need better control over the low bitrate quality)....Else, Exhale needs to be able to accept exhale files as valid input, to save the poor hard drive.

Exhale clearly beats opus and fdk <24 kps on my equipment (pc speakers, pc head phones, foobar, phone with car bluetooth and phone with ear piece.  Exhale is clean sounding, while Opus has and irritating grain on the peaks, which upping it to 27 kps, trying to tweak frame duration/encoder compression/application switches and 10k lowpass didn’t remedy....FDK is clean, like Exhale, but vbr doesn’t seem possible, only abr of 22kps was acceptable, while Exhale could surpass FDK quality at 18kps for the same file.
 I also think fdk was flirting with a barely perceptable metallic artifact more common in Lame at low bitrates, at 22 kps abr....xHE-AAC failed on file size and price.

I think exhale wins hands down, but will cost me $40 in an external hard drive that I wouldn’t otherwise need, since piping ffmpeg to exhale, on windows doesn’t obey needed arguments!

:::::::::::::::::::::::::::::::::::::::
      :The key dos bat file lines to get clean 17 kps files with Exhale--without piping--  are:

ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -t  %seconds% -ac 1 -f wav  -acodec pcm_s16le -metadata album="%album%" -metadata title="%album%" -metadata artist="%artist%" in.wav

start /high /wait /b exhale.exe b in.wav %album%.m4a

start /high /wait /b ffmpeg -i "%album%.m4a" -acodec copy -metadata album=%album% -metadata title=%album% -metadata artist=%artist% %album%_%artist%.m4a
del %album%.m4a

wput -nc -t 3 -T 24000 -B -u %album%_%artist%.m4a ftp://UserName:Password@ftp.somewebsite.com:21/%album%-%artist%.m4a

:::::::::::::::::::::::;;
Sadly, no luck with piping ffmpeg to exhale. So, will need to pay for an external hard drive that I don’t use for backup, nor care too much about burning out by constantly writing hundreds of gigs of wav files per month.
 

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #5
Hmm, a 2 step Exhale bat for recording long speech won't work on fat32;  I just remembered that the maximum file size for ntfs is 4 gig.  This is only about an 8 hour audio wav file.   I guess it will work on NTFS or exFat.  Correct me if I am wrong. (I am reading exFat is faster than NTFS at large file transferring, but I am not sure if I believe it is not just an urban myth, as no proof or graphs or stats are offered.)

Anyone get piping working of their sound card or virtual sound card to Exhale exe on windows?  I guess, I got piping to exhale to technically work on windows, but all the options broke, and the files were 6 times larger than what I need. So, functionally, it didn't work for the purpose of speech encoding.  I would be fine with the exhale file size and quality piping outcome for music. 

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #6
Have you tried this program for Windows?
https://www.poikosoft.com/music-converter

A mono wave file at 48kHz occupies 345.6 MB/hour

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #7
I have tried that program. What is the trick with xHE-AAC and the program? But could not figure out how get an xHE-AAC speech file under 29 kps.  I have been encoding my speech files (an average of 18 kps, ranging from 14 or 16 kps to 23 kps, but seldom above 21 kps ) to listen to during the week, since at least 2005, with lame/a bunch of tricks on the vbr/low pass of 7800, which are pretty artifact free and higher low pass than most of AM radio stations I listened to for the prior 17 years.... It is 2022, I mean 2023, and I know that high quality sub 24 kps encoders are possible. And we are still talking hundreds of megs per audio book like file, which can rack up into 100 gigs if you want a big selection at your fingertips.

So far, exhale via bat file is the most practical for doing the recordings all year long.  Dos scripting is pretty easy to learn and relearn., because of its intuitive structure and documentation online.

If I only did 40 hours worth of audio encoding per year, I would stick to foobar2000, use the instruments to configure a custom encoder that uses exhale.exe.  It encodes a target of 24 kps with option 'b' for quality if the input is mono.  It's a quality setting was an  18 kps target that it wasn't very good at.  I will need to test a 7800khz to 18.6khz low pass wav, and see if I can get closer to an 18 kps exhale without the too noticeable artifacts. 

I was able to use the Dos and poikosoft to get fdk lC aac files circa 22 kps, which did not have the annoying grain that opus files have at the bitrate.  However, Exhale files beat the fdk files in efficiency.  I am not sure if exhale has a better vbr algorithm or if it is some other sbr like trick.

I am sure xHE-AAC would beat Exhale at speech <24 kps targefs, but there is not a free way to encode with xHE-AAC that I can find.  Also, poikosoft customer service has not responded to my Facebook and emails asking how to get really small but rate files. Their gui is too limited in the choices possible for xHE-AAC, and I suspect that a windows registry setting or buried poikosoft app data file, could be edited manually to hack the settings and get the desired target bitrate for the xHE-AAC.... I would only consider the premium xHE-AAC route if u could get high quality 18kps vbr files for speech.

I expect lots of improvements with exhale in the coming year (hopefully, pipe from sound card instructions, then an ffmpeg plug in if that still fails) , as well as with poikosoft's limited that restricts choices.

I am not happy with the hard disk wear and tear that Exhale encoding seems to require, doing it the less labor intensive way via a bat file.  So, I ordered a $14 Samsung 128 gb thumb drive that barely sticks out of the computer. I need only a single folder on it with the bat file, exhale.exe, ffmpeg. Exe. Wput. Exe, and an optional ahk file to auto start the player/launch the browser for album art and reviews/message box entry for variables and white space removal and write the bat file on the fly instead of manually editing.  Although, I will stick to editing my Dos variables at the top of the file, and simply use the ahk to launch notepad to edit bat, wait until saved and closed start the player, run the recording bat file, with Exhale as the default codec and launch the browser with a search for the art and reviews that I will need to manually save.

I tried to use wget to automate the image and review grabbing, but it looks like I would need a fair bit of scripting (to get the links, retrieve the links, fetch a usable synopsis or review, and fetch an image) and relearning curve (I have done similar stuff, but would need to relearn how.) It takes about 5 to 10 minutes to do this manually each recording. it is likely that ffmpeg could add album artwork to the Exhale m4a files. (It was a pain to get the syntax correct to tag the exhale files because tagging requires stream syntax on modern files but not on mp3 files. So, it would be nice for others to be able to add tags with exhale.exe arguments.) But I haven't researched how to add images to exhale files by using ffmpeg just yet..... I really like to see the track's image or art, especially when playing audio on the car stereo...

.


I

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #8
If direct piping is an issue you could use a ram disk if you have enough ram. ffmpeg would write to the ram disk, then separately exhale reads a complete wav file that never hits the HDD. A USB stick especially a $14 one will be even more of a bottleneck than a HDD but it will work if that's the only way.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #9
If direct piping is an issue you could use a ram disk if you have enough ram. ffmpeg would write to the ram disk, then separately exhale reads a complete wav file that never hits the HDD. A USB stick especially a $14 one will be even more of a bottleneck than a HDD but it will work if that's the only way.

This is an excellent suggestion, which would work half of the time.  I used to use ram disk on LP restoration for the wav steps, like 19 years ago.  I am seeing ffmpeg saying it is encoding the mono wav at 700 kps, not the 384, at 44.1kz. (I removed the -ar, since resampling the supposed 48 khz seemed to lower the quality (I tried 32000 and 22050 hz resampling.  Key word is seemed, I guess, with only 1 or 2 tests.)....I am open to resampling suggestions by people who have tried it.  I might have just had a fluke sample, and resampling to 22050 has no effect on the final Exhale file.

I have about 12 gigs of ram, and could allocate, maybe 6 gigs, which wouldn't be enough for many of my intended recording sessions.

I should report that on a cheaper usb thumb drive, probably claiming usb 3.1, from Walmart, I tried all last night to record 8 hours of speech for the exhale.exe.  It would record several hours fine, but eventually fail.  ( I checked, and usb suspend is disabled in the power profile. advanced setting.)

Today, I noticed the ffmpeg speed stat was a tad under 1 x for the pcm 16le wav encoder.  I bet the lagginess of the thumb drive was borderline acceptable and the recording and exhale encoding failed.  I wasn't awake for the last failure, so I don't know for sure.

I am testing my external 5400 usb drive, that I taped to the bottom of the laptop, now, which should be faster, but wont know for sure for many hours of recording.  It is a 320 gig Toshiba, but only has about 10 gigs free after its use as a backup for the internal drive essentials, including family photos and videos.   10 gigs will cover about 70 percent of the wav files I wish to make for the Exhale.exe to encode.

I now store my laptop in a Tupperware like container when I am not using, after someone broke the screen last month and I had to buy a  new screen, which is fits, with little room on the sides.  So, I am hoping the Samsung flash drive is as fast as they claim, because it barely protrudes from the usb port. I bet the usb cord from my port to the external HD (taped to the bottom of the laptop), semi-permanently attached and sticking out, will eventually wiggle the usb plug from the circuit board, especially when replacing in a tight protective bag or box.  But, it is unlikely that any usb thumb drive will live up to their promises, under $100--even Samsung.  I have had early failing micro sd cards from Samsung fail in mere months.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #10
Hello,

Try:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -c:a pcm_s16le -f wav - | exhale b out.m4a

I have already done ffmpeg -> exhale piping without any problem. Christian had made some corrections more than two years ago to ignore metadata in wav files (https://hydrogenaud.io/index.php/topic,118888.msg984703.html#msg984703), to support mono/24/32bits extensible wav files (https://hydrogenaud.io/index.php/topic,118888.msg985137.html#msg985137), etc.

    AiZ

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #11
Hello,

Try:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -c:a pcm_s16le -f wav - | exhale b out.m4a

I have already done ffmpeg -> exhale piping without any problem. Christian had made some corrections more than two years ago to ignore metadata in wav files (https://hydrogenaud.io/index.php/topic,118888.msg984703.html#msg984703), to support mono/24/32bits extensible wav files (https://hydrogenaud.io/index.php/topic,118888.msg985137.html#msg985137), etc.

    AiZ


I tried this, but was only getting 117 kps stereo files.  I am looking for speech at around 24 kps mono.

Make sure you are using the -t 3600 ffmpeg switch to limit the duration of the recording.  This is an essential ingredient in a bat file to reduce the time a human must spend over the course of a year or decade.

I am in the middle of recording a 31 hour lecture.  So, I will cut and paste your line tomorrow.  Hopefully, I had some typo.

I just discovered Exhale last week, so should have the latest gitlab version of the exe.  1.2, I recall.

Sound testing yesterday, results:  I found that playing the books through the Lg G8 built in phone speaker, the Opus artifact of peak grain wasn’t reproduced, while the exhale 24 kps files had the slight artifact where it sounded slightly like the phone was in the bottom of a tin garbage can.  So, on that particular phone speaker, Opus won the contest .. When I switched to my $30 bluetooth ear piece (foam passive noise canceling ear insert which exaggerates bass) or the cheap$5 to $10 plugin ear buds, neither 24kps format had artifacts to speak of, but the android maudiobook player was able to boost more highs in the exhale file with its equalizer, making it sound more like a higher bit rate file.

I was a bit disappointed hoping Exhale would be the clear winner on every set of speakers.

Apparently, Opus is filling in missing information with a grainy hiss sound, while Exhale tries to reproduce the information, with the familiar, barely noticeable, metal-can artifact. (I noticed Opus grain is audible up to 27 kps target kps.)  I personally find the grain of opus more irritating, and its artifact seems to be audible on more speakers that I have tested so far. I do not expect artifacts at 24 kps with a modern encoder of speech, based only my success with highly listenable 18kps speech files using lame switches, 7800 hz lowpass, back in 2005. I would expect slightly or barely audible artifacts on 18 kps files, in the modern age.  I think the problem is mostly lack of development in these low bit ranges, lack of Opus and Exhale developer interest and not grasping the <24 kps possibilities--rather than any technical barrier.

Another hypothesis for <24 Opus grain or any <24 kps Exhale artifact, might be that there could be end result variance, because of the underlying characteristics of the apparently studio quality wav,  base of the brand of sound card and its wav encoder.  Else ffmpeg just sucks ar mixing to mono or resampling....To be fair, I have only tried the ffmpeg to opus directly, and not tried an intermediate wav then opuenc.exe , except using foobar2000, where I could still hear grain in the <24 kps Opus transcoded from much larger aac files.

For example, I am using a-b cable which is a high quality, lossless Chrome>ffmpeg.exe to wav to Exhale or Opus encoders.   Mmsys.cpl says 48 khz, but ffmpeg grabs the 44.1 khz, unless I use -ar 48000 argument.  If I use the -ar 32000 ffmpeg argument, there is a buzz in the peaks that is intolerable.  If I use the -ar 22050, there is a peak static artifact.  16000 and 11025 , both sound horrible.  Resampling never introduced hiss or buzz on my old machines, using other tools than ffmpeg to do the resampling, in the past ...On my old machines, resampling the wav to mono 16000 hz for the lame encoder seemed to work fine, and there were actually less artifacts at a given vbr bit rate (contrary to the frame theory where smaller frame artifacts mean less humanly noticed because they are shorter)  and encoding went faster. ...

To sum it up, hypothetically, the encoding sound card and the playback speakers (etc) and playback sound shaping programs, might affect the perceived winner between Opus and Exhale as the winner in Jan 2023 in files <24 kps speech files.   But, Exhale beats the Opus peak grain/chest rattle for most of my equipment so far.

Also, oddly, I can get Chrome to play the m4a Exhale files in the browser (which is great to preview the length, content, and quality of the production), while Opus files need to be downloaded in full.  This is opposite of what I have read.


Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #12
Hello,

Try:
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -c:a pcm_s16le -f wav - | exhale b out.m4a

I have already done ffmpeg -> exhale piping without any problem. Christian had made some corrections more than two years ago to ignore metadata in wav files (https://hydrogenaud.io/index.php/topic,118888.msg984703.html#msg984703), to support mono/24/32bits extensible wav files (https://hydrogenaud.io/index.php/topic,118888.msg985137.html#msg985137), etc.

    AiZ


Thank you.  Success finally.

I don't know what my typo was.  Probably the order of operation or the syntax you use, c:a , works.  Without piping, maybe the ffmpeg order of arguments or syntax isn't as picky as when piping to exhale.

I think the combination of reordering or syntax allowed the correct wav format to be piped to exhale.

This is my dos bat line that finally works to pipe (after beginning of the dos having 17 set variables that can be edited before run (4 variables change each session), then stripping out the whitespaces in the variables, then doing the second calculation and other variable manipulations:

if %UseLowPass%==yes (ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" %monovar%-c:a pcm_s16le -f wav -t %seconds% -ar %Resampling% -af "lowpass=%lowpass%" - |  exhale %ExhaleQuality% %album%.m4a) else (ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" %monovar%-c:a pcm_s16le -f wav -t %seconds% -ar %Resampling% - |  exhale %ExhaleQuality% %album%.m4a)

I recorded a bit over 15 hours last night to a wav on a ram drive for the exhale.exe.  I hypothetically could get about 20 hours before running into disk full on the ram disk.  So, I hit q on the terminal to end the wav recording and start the exhale encoding early at the 15 hour mark.  ....The wav was corrupted after the 12 hour mark.  Fortunately, Exhale.exe encoded the 12 hours fine in a single uncorrupted file.  I can now resume part 2 at the 12 hour mark. 

Actually, half of the time ffmpeg miscounts time on all formats.  It is not reproducible between sources, I haven't tried same file.  Typically, I believe, ffmpeg undercounts by 2 minutes per hour.  So if my source is 12 hours, I might need to add 24 minutes to the -t argument on ffmpeg, or I miss the last 24 minutes of the recording.   I suspect "A non monotonous source, resulting in miscounting of the output file" is the cause. I suspect, but don't know.  Obviously, I need a mono files, else exhale.exe will encode a huge speech file.   On opus stereo on speech only added like 2 kps onto a 24 kps file.  Even 2 kps adds up to lots of hours on a gig of storage, as the bit rates drop closer to 12 kps (I have no ambitions to go below 18 kps for the averag speech file, because I suspect the quality trade offs would be too apparent for each kps, based on my lame days.)

Because of the ffmped miscount, I would like to add an end silence detection of like 45 seconds of silence to stop the recording, in addtion to adding 2 minutes per hour for the -t argument.   I have had mixed success with my resulting argument, based on lots of googling and ffmpeg docs (which usually lack solid example lines needed to fully comprehend the explanations).   I figure, that recoding from the sound card, maybe the silence detection might not apply, as with file transcoding; maybe, my sucesses after a 18 hour recording session were just a fluke of miscounting, adding time, equaling the correct stopping point.   If you know the correct syntax there, please help me out.   ....I was trying to use an -af, which doesn't make sense to me on a live recording session: -af silenceremove=stop_duration=45:stop_threshold=-50dB

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #13
I have had repeated failures with exhale.exe at getting more the 12 hours and 25 minute recordings or transcoding.  I just noticed the other files that I did with exhale from a wav were all under 12 hours.

I have had no problems getting 18 or 24 hour opus recordings.  I think I got long fdk ones, but it is unlikely, as I  didnt try too many files due to the lack of vbr (only abr worked, which was of inferior quality to exhale b setting, while exhale a setting files are smaller yet sound as good or better then fdk 22 kps cbr.)

So, I am now thinking that exhale.exe can only handle 12 hours and 25 minutes per track or file, because the maximum file length is extremely consistent 3 failures in a row, at 12 hours 25 minutes and 39 seconds, using both pipe and wav to m4a.

So, for my desired single 31 hour track, I got 3 parts on 3 tracks.  ...  If this holds, I suppose I could constrain each track to 10 hours, since I get to my computer once every 12 hours, plus or minus 2 hours.  If early, 10 hours would allow the next track to start, rather than waiting for the last track to finish.  Of course, this will require more manual work, actually getting back to the computer, and not to forget about the recording project... 

Need confirmation by others to know for sure.  Plenty of hard drive space here.  It may be that 149,000 or 150,000 megs per file is the maximum file size that exhale will write, rather than a limitation of 12 hours 25 minutes and 39 seconds, which would be more logical, although the consistent cutoff down to the second is very suspicious. But so is 150,000 megs which looks like a humanly chosen arbitrary number that the Exhale developer might have not been able to imagine the need for a bigger file....

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #14
Hi,
So, I am now thinking that exhale.exe can only handle 12 hours and 25 minutes per track or file, because the maximum file length is extremely consistent 3 failures in a row, at 12 hours 25 minutes and 39 seconds, using both pipe and wav to m4a.
Uh... No.
exhale limitation with wav files is that it reads "classic" WAV file format only. If you look at the source code, you'll find a 'basicWavReader.cpp' file, the name says it all.
Historical IBM/Microsoft wav files are limited to 4GB.

Your input file is either mono 48Khz ( ((12x3600)+(25x60)+39)x48000x2 = 4 294 944 000 bytes) or stereo 24Khz, hence the 12h25m39s limit.
You can reach 13h31m35s with mono 44.1Khz or 18h38m28s with mono 32Khz.

    AiZ

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #15
Hi,
So, I am now thinking that exhale.exe can only handle 12 hours and 25 minutes per track or file, because the maximum file length is extremely consistent 3 failures in a row, at 12 hours 25 minutes and 39 seconds, using both pipe and wav to m4a.
Uh... No.
exhale limitation with wav files is that it reads "classic" WAV file format only. If you look at the source code, you'll find a 'basicWavReader.cpp' file, the name says it all.
Does that explain why it fails also when using pipe?

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #16
Hi,
So, I am now thinking that exhale.exe can only handle 12 hours and 25 minutes per track or file, because the maximum file length is extremely consistent 3 failures in a row, at 12 hours 25 minutes and 39 seconds, using both pipe and wav to m4a.
Uh... No.
exhale limitation with wav files is that it reads "classic" WAV file format only. If you look at the source code, you'll find a 'basicWavReader.cpp' file, the name says it all.
Does that explain why it fails also when using pipe?

Good question.   I guess his explanation explains why the two wav attempts cut off at 12:25:39, but it would be so much nicer if Piping to exhale used a continuous wav without these limitations, which will add days and cause more manual work track restarting for long session recordings, unless a different codec is chosen.

Unfortunately, resampling to 32 kps has a loud buzz, 22050 has a nasty scratchiness, that lame never had on the old machine.  I could lower it to 44.1, which seems about the same as 48000.  I just read that the higher sample rate, smaller frames or something, and less artifacts, which probably doesn't apply to voice anyway.  Getting and extra hour, isn't going to change how many days it will take to record say an 80 or 40 hour worth of speech.  I regularly get to my computer every 12 hours, plus or minus 2 hours and I do not have a predictable schedule at all, my work day could be 4 hours or 14, and I have no idea until the day is nearly done and I find a good breaking point.  So, recording sessions of 13 hours can be covered, but anything over, and I will need to choose 10 hour tracks, with a maximum ability to record 20 hours.....even with the pipe command, sadly.   Else, I will need to go with the grain filled opus format, or the more worbly fdk at a 24 kps abr, which would pain me, because I am really sold on Exhale and its 20 and 24 kps speech ability and quality.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #17
If it is a "wave" file that is too long, it is not compliant - so have you eliminated the issue that whatever you use to feed it to pipe could actually refuse to output it?

If you try instead from a format that allows it - say flac or wavpack - they can decode to stdout without that length constraint. Also foobar2000 when set up with an external encoder.

 

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #18
If it is a "wave" file that is too long, it is not compliant - so have you eliminated the issue that whatever you use to feed it to pipe could actually refuse to output it?

If you try instead from a format that allows it - say flac or wavpack - they can decode to stdout without that length constraint. Also foobar2000 when set up with an external encoder.

I am having a hard time understanding, because I am trying to record directly from my sound card, using pipe

ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" %monovar%-c:a pcm_s16le -f wav -t %seconds% -ar %Resampling% -af "lowpass=%lowpass%" -af silenceremove=stop_duration=45:stop_threshold=-50dB - |  exhale %ExhaleQuality% %album%.m4a

Which is basically,
ffmpeg -f dshow -i audio="CABLE Output (VB-Audio Virtual Cable)" -ac 1 -c:a pcm_s16le -f wav -t3600 -ar 48000 -af "lowpass=10300" - |  exhale b output.m4a

If I don't resample it gives me 44100, which sounds fine.  Unfortunately 32000 and below sound horrible.   10.3 lowpass sounds identical to no low pass, except for a few less fringe artifacts that are so minor, I could be imagining it.  10000 lowpass is a must for the quality A in exhale...... 

 Since FFMpeg is pumping  a continuous stream to exhale, it is not a file per se.


Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #19
Sorry, noticed this discussion just now. exhale, if I remember my own code correctly, cannot read more than 4 billion PCM samples in one encoding, due to the restriction AiZ mentioned above. If you need to encode between 12 and a few minutes less than 25 hours of audio, you could try exhale's preset 0 (instead of b) along with an audio input sampling rate of 24 kHz and mono input. Then you wouldn't need the additional lowpass setting, by the way.

It's not a perfect solution, if I understand you correctly, but that would allow you having to check, i.e., restart very long encodings exactly - and only - once a day, at roughly the same time (within a time window of 51 minutes). It might also make archiving relatively straightforward since each resulting .m4a file corresponds to a calender day.

Chris
If I don't reply to your reply, it means I agree with you.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #20
Sorry, noticed this discussion just now. exhale, if I remember my own code correctly, cannot read more than 4 billion PCM samples in one encoding, due to the restriction AiZ mentioned above. If you need to encode between 12 and a few minutes less than 25 hours of audio, you could try exhale's preset 0 (instead of b) along with an audio input sampling rate of 24 kHz and mono input. Then you wouldn't need the additional lowpass setting, by the way.

It's not a perfect solution, if I understand you correctly, but that would allow you having to check, i.e., restart very long encodings exactly - and only - once a day, at roughly the same time (within a time window of 51 minutes). It might also make archiving relatively straightforward since each resulting .m4a file corresponds to a calender day.

Chris

Thanks Chris.

So, I used "-ar 22050" (mono) and "exhale 0 output.m4a" in my pipe statement.  The bit rate and my first impression on the sound quality, seems identical or very similar to the b setting at the regular sample rate.

Question,  does this mean I am getting nothing on speech files from the HE as used by the alphabet quality settings? Or am I gaining highs that my earbuds aren't reproducing with HE on B instead of 0?

I will note that if I resample lower than 44.1 kHz, I get a buzz at 32000 and scratchiness at 22050 when using the alphabet quality settings of Exhale.  This is also true when encoding to Opus files.   (*Although Exhale b sounds better than Opus. Opus, starting around 27 kps,  gets an annoying (once you realize it is there) peak grain, which sounds like the speakers have pneumonia and I want to cough for them.  The grain in Opus gets more aggressive as you lower the bitrate.  Exhale b quality files, also equalize better on my android player than opus at these low bitrates on speech. )

Resampling with ffmpeg:  Since I am using ffmpeg, I think they only allow -ar resampling at 48000,44100,32000, 22050, 16000, 11025.  If I put in 24000, I recall it rounding to 22050. There is supposed to be -af "aformat=sample_fmts=s16:sample_rates=%Resampling%"     doesn't seem to work, since the console is saying a regular sample rate, and the playback of the Exhale file is 44.1 or 48 kHz (I don't recall which.).

Of course, I am more interested in your thoughts about Exhale's b quality vs. 0 quality at 22050hz, and the role of HE in voice at <24 kps.  (I assumed High Efficiency meant more efficient.)


Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #21
Hello,

Resampling with ffmpeg:  Since I am using ffmpeg, I think they only allow -ar resampling at 48000,44100,32000, 22050, 16000, 11025.  If I put in 24000, I recall it rounding to 22050. There is supposed to be -af "aformat=sample_fmts=s16:sample_rates=%Resampling%"     doesn't seem to work, since the console is saying a regular sample rate, and the playback of the Exhale file is 44.1 or 48 kHz (I don't recall which.).

ffmpeg has no problem to resample to 24Khz. In fact you can input whatever value: 24000, 12345, 501, etc. Now, container/codec supporting these unusual rates is another problem (wav is Ok).

If you like to have placebo extra quality, add
Code: [Select]
-af aresample=resampler=soxr:precision=28
after your -ar %Resampling% parameter.
FFmpeg Resampler Documentation

    AiZ

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #22
does this mean I am getting nothing on speech files from the HE as used by the alphabet quality settings? Or am I gaining highs that my earbuds aren't reproducing with HE on B instead of 0?

I will note that if I resample lower than 44.1 kHz, I get a buzz at 32000 and scratchiness at 22050 when using the alphabet quality settings of Exhale.
The alphabet presets activate SBR encoding for high frequencies, starting at a quarter of the input sampling frequency. So at, e.g., 32 kHz sampling rate, that's 8 kHz, which is so low that SBR artifacts become audible. Hence, use the non-SBR numeric presets with low input sampling rates.

Chris
If I don't reply to your reply, it means I agree with you.

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #23
does this mean I am getting nothing on speech files from the HE as used by the alphabet quality settings? Or am I gaining highs that my earbuds aren't reproducing with HE on B instead of 0?

I will note that if I resample lower than 44.1 kHz, I get a buzz at 32000 and scratchiness at 22050 when using the alphabet quality settings of Exhale.
The alphabet presets activate SBR encoding for high frequencies, starting at a quarter of the input sampling frequency. So at, e.g., 32 kHz sampling rate, that's 8 kHz, which is so low that SBR artifacts become audible. Hence, use the non-SBR numeric presets with low input sampling rates.

Chris

Interesting.

I am getting 23 to 25 kps, resampling speech to 22050 hz, lowpass 10300, and Exhale 0.

I would like to play around with speech bit rates closer to 21 through 18 kps, to see if it is possible to get reasonable files in those bit rates...... I did only one speech file so far with Exhale on the  A mono setting, and got a 20 kps, which didn't sound too bad.  

[I like and appreciate a 10300 low pass, barely can hear anything in the human voice above this (not worth encoding outside of background sound story telling).  But, I have been happy with 8000 lowpass for many decades, as there is no intelligibility information between 8 and 10k, according to Science Direct and my own empirical tests.  I have been listening to tens of thousands of hours of speech, while doing other things, for the last 15 or more years, that I encode with pretty artifact free 16 to 23 kps Lame mp3's.   I used a bunch of tricks and switches to achieve this.  I just decided to switch to Opus, then Exhale, in December 2023. .... So far, there is no difference in bit rate using a lowpass on Exhale, but I suspect (more testing needed) that using a more aggressive lowpass, I could get a lower bitrate and no annoying artifacts on speech.  (Specifically, I remember settling on 7800 lowpass, with Lame circa 3.93 to 3.97 plus a bunch of switches I needed that they turned off in later versions of lame that I relied on. My target was 18 kps mp3s that sounded like 28 kps and less artifacts than most people's 32 kps.)]

Re: [split] Help with long files (over 8 hours) using exhale encoder

Reply #24

I am getting 23 to 25 kps, resampling speech to 22050 hz, lowpass 10300, and Exhale 0.

I would like to play around with speech bit rates closer to 21 through 18 kps, to see if it is possible to get reasonable files in those bit rates...... I did only one speech file so far with Exhale on the A mono setting, and got a 20 kps, which didn't sound too bad.
That sounds reasonable, but you shouldn't need the extra lowpass with preset 0 then since the audio bandwidth is only 11 kHz anyway with 22050 Hz sampling rate (for up to 27 hours and 3 minutes of encoding at once, if I calculated correctly). Modern encoders are much more intelligent in choosing how many bits to spent on high-frequency coding, you don't have to worry about these things anymore (it's basically a relic from "old mp3 ways of audio coding").

Chris
If I don't reply to your reply, it means I agree with you.