This will be vouched by anyone who has used audacity to precisely note down the section beginning & ending times for its removal. Then, with ffmpeg, for slicing a file into separate segments, then joining the two segments back with the undesired section removed, the surgery doesn’t bloat up a file. Rather, the file-size is proportionately reduced.
However, in audacity, the direct open,edit,save (later addition for clarity: Open a File, then Edit to cut undesired sections, then Save the edited file, all steps for a single file) always bloats up a file with audacity. Definitely so with .ogg files, that I have repeatedly experienced.
Can’t the advantages of using the ffmpeg visually in audacity be utilised?
Any creative input please?
There are a few GitHub projects on GUI/Visual ffmpeg, like say:
FFmpegFreeUI
ffmpeg-commander
Shutter Encoder
Edconv
Videomass
etc., searchable with ffmpeg-gui · GitHub Topics · GitHub
But I am unsure about which to use, particularly, if a Chini product.
Thank you, Mr. Trebor, for replying to my post.
I wasn’t talking about Projects, instead, I was talking about files. Please go through my question head again: I was talking about file & filesize for a particular filetype (extension name).
I was talking about any audio file, like say a file with a specific filename, filename.ogg, before editing & removal of a section; then save this file filename.ogg after opening, editing, removal of a section, i.e., saving the result, as an easily identifiable copy of the earlier file with filename filename.ogg, but same file extension/filetype, say for example, filename1.ogg & so on for repeated editing, trimming, saving.
Any user could test this with any arbitrary file, by proceeding to editing & cutting a section, then saving it with a different filename but with the same extension type, and comparing the filesizes.
The same inflating of filesize doesn’t happen with ffmpeg.
Mr. Trebor, you are unduly including unnecessary complications in to a straightforward problem. The ogg standard I follow is universal:
bitrate: 100 kb/s to 115 kb/s (depends on the file’s audio content, rather than my settings), Stream #0:0: Audio: vorbis, 96000 Hz, mono, fltp, 4294967 kb/s.
This is generally the standard I follow for my created/modified ogg files.
What you say about lossy, etc., is already known.
Please Note the logic:
The same files have different outcomes in audacity & ffmpeg when a pre-determined, exact part is removed. Please don’t engage in theoretical exchange, but try yourself one by one, first with audacity, next with ffmpeg, for cutting an identical audio section from a mono ogg file that you created for experimentation.
But the file must be long for experimenters to observe the differences clearly.
The file size is directly related to bitrate (kbps = kilobits per second).
There are 8-bits in a byte so divide by 8 to get kilobytes per second.
This doesn’t include any embedded artwork.
Some encoders or settings allow you to directly set the bitrate and in other cases you choose a quality setting and it figures-out the required bitrate for that quality. If you aren’t directly choosing the bitrate, different encoders may give different results.
If the sample-rate of the original file is a more reasonable 48000Hz, and you’re exporting at 96000Hz, that resampling could produce an edited file of shorter duration, but taking up more memory than the original file.
Thank you, Mr. DVDdoug & Mr. Trebor for replying to my post.
Why does it appear to me that the either of you are missing the forest for the trees? It seems to me that you have read my introductory post on this subject, but not sitten back, reflecting on the Big Picture that is sought to be gotten across to you, my seniors & leaders. To me your approach comes across as superficial beating around the bush.
I tried to add further clarity to my first post by adding a few words/rephrasing. Please reflect on the first post, contemplate. Please try, as informed, for a sample, long, audio file, with both audacity & ffmpeg, separately, like I have tried to illustrate, then observe for yourself the difference.
By your experience with my approach, going through my interactions & history, I am sure you will appreciate that when I have identified some flaws & have stuck to my line of argument I am usually correct. Please. Contemplate. Reflect. In precisely the same steps as I’ve mentioned. Empirically observe the outcome of the experimentation.
Thank you.
Assuming you’re talking about the aup3 file bloat and not export (ogg/mp3/etc) bloat, I’ve had aup3 files blow up to 50 gigabytes just from a bunch of cut and paste between tracks. The only way to cope if you have limited disk space is to periodically remix the tracks, although this unfortunately destroys the visual information of the source track names and separations between pasted segments, making my subsequent editing harder as I have to re-listen to figure out what each bit is.
Remix each track (not combining, just remixing with itself) and your file size goes way down.
File size is mathematically related to bitrate and playing time (again ignoring embedded artwork). There is no ambiguity. A 256kbps file is 256kilobits per second = 32kilobytes per second, PERIOD. (Maybe some tiny variation or rounding of the bitrate.)
That would be the overall average bitrate which may vary with different OGG encoders. I don’t use OGG but I believe with OGG you select the “quality” and the encoder determines the required bitrate for that quality. You might get a slightly a different bitrate with different OGG encoders or if you open (decompress) and then re-encode the OGG file.
You can check the actual bitrate of the files with MediaInfoOnline in case you’re not getting what you are expecting.
Already been given.
I have used words like empiricallarge for files, in order for experimentation to indicate the comparative bloating, such as.
and
Also given other values such as:
You need to keep the ogg quality, compression, etc., unchanged for testing:
I am surprised!
3 min = 180s gives 4mb size. Please try exact byte or kilobyte size.
(4096/180)*6 = 136.53 kb
=(4096-136.53)/1024 = 3.87kb
In this case, bloating can’t be clearly determined.
A large enough filesize & long enough audio, say 20 min, would yield better results.
Remember to keep the same set up & values for ogg compression. Note the values & keep them unchanged for repeated experimentation. Use the same set of steps with ffmpeg also for comparison.
I did another test in Audacity. Started out with a 25 minute ogg, 37.7mb (39,577,253 bytes). Deleted 10 minutes, saved as ogg2 (15 minutes), 23.2mb (24,378,865), re-opened ogg2 and deleted another 10 minutes, saved as ogg3 (5 minutes), 7.84mb (8,223,926 bytes)
In general, it’s not a great practice to re-encode already lossy files to another lossy file -each time you do it the sound quality deteriorates.
Thank you for your attempt.
There needs to be a slight adjustment: the deleted section must be very small, a few seconds at most, to catch & observe the flaw in the re-enconding process, in comparison to the same process in ffmpeg. Not huge chunks. For the either of the cases, one with audacity, one with ffmpeg, the removed segments should be identical.
You could also open & re-save without deleting anything as a second copy to observe the flaw in audacity.
ffmpeg line, from initial to final time (you could use a dot for milliseconds:
Yes. True. Not only the audio quality degrades, but filesize also bloats up for Audacity. But sometimes, editing to delete segments in earlier editions of an audio file can’t be avoided. It was only during such cases of unavoidable deletions that I observed the shortcoming in this regard in audacity.
Your use of -c copy in the FFmpeg command line does a straight copy of the existing data, edited for time.
On the contrary, opening and resaving in Audacity does a full uncompress and recompress of the data -it’s no surprise you’ve seen differences comparing the results, it’s two completely different methods
Which I suppose, is the real “drawback” of using a normal audio editor. The quality loss from multiple generations of lossy compression can accumulate.
And since the data is slightly different each time you could get slightly different file sizes.
Yes, of course. It helps when just “open, delete-segments, save” steps are required, without unnecessary complexities.
If I have overlooked, please consider enlightening me with a similar set of steps in Audacity that replicates the same set of steps of ffmpeg, but in audacity.
Audacity being visual, is a great tool to edit audio visually, is a far better/endowed application, but ffmpeg has one great step that helps, as stated earlier.
Yes, I am in need for an audacity interface, a shredded one, with only the ffmpeg functionalities of ONLY copyingwithoutre-encoding to be handled via the GUI interface of audacity with its visual wavetable representation for easy identification of sections to be removed.
I await Mr. Steve, who is my leader, & whom I consider the master of the Audacity universe, but he hasn’t still arrived yet.
With this post I will again risk attracting the self-appointed pontiffs, who would ignore the inputs that I have already provided, like the utility of the visual wavetable interface of Audacity.
Needless to say, I already presently use Audacity to identify which parts to remove. Then I use ffmpeg to create piece-wise clips then join them into one file.
I’m sure I am going to regret replying, but once more into the fray…
Anyone with a text editor can write a script for FFMPEG to extract clips of audio and copy without re-encoding to a new output file. You don’t need Audacity at all to do that. You are asking them to create something that you should do yourself.
