How to batch convert music albums & the cover picture into .avi files?

[TB-303]

Hello,

I'm sorry if this was already asked (I am kinda 100% sure, but could not find anything using the search function).


I have A LOT of music albums (over 60 folders) with WAV files and already correct sized cover pictures (PNG) in 1280x720 in each folder.

I already found here how to easily make a video out of just a single picture in VirtualDub with "source rate adjustment" and "frame rate conversion" function.

And it's also easy to pick one WAV file via "audio from other file" and safe it together as AVI with the name of the WAV file.


but I don't want to do this 650 times by hand for each audio track, apparently...

so how can I do this in a batch?


if you didn't understand it exactly yet:

a still picture (cover.png, 1280x720) should be converted to AVI (1280x720), using x264 codec, containing one audio track (WAV) per video, with the video duration matching to the audio duration.

also the file names must match: 01-Artist - Title.wav -> 01-Artist - Title.avi


if there are better tools which could do this easily, I am open to switch. I'm not bound to use VirtualDub.


thnx in advance!


best regards



PS: it's for YouTube and it's legit, because I do this for the record label which released all these albums!

[videobruger]

Like this:

https://forum.videohelp.com/threads/387935-BAT-File-Problem-Adding-Image-To-Audio-Using-ffMPEG

But:
How are the names of the png files related to the names of the wav files?
Why AVI. Youtube change it anyway?
x264 is not a codec. It's an encoder. It uses the h.264 codec.

best regards

[TB-303]

will check that out thnx!

currently there is one PNG file per folder, named CatNr.png (e.g. ABC001.png).

well I'm used to AVI but every other format is fine too, I guess. It must support PCM audio though.

and I don't want to get into splitting hairs, but isn't it officially named x.264 (the free version) and just _based_ on the not free h.264 codec???

at least that's how I understood it.

[Cornucopia]

X.264 is a codec (aka COmpressor - DECompressor). It is an application library, built to be compliant with the AVC/h.264 format specifications (at least, a major subset of them).
Mainconcept also has an h.264-compliant codec. So does Apple. So does Cisco, with "Openh264". The spec doesn't say how to build the app nor how to put together the media stream, it just says, "if you want it to be properly played back in a consistent and compliant way, you must follow these rules of structure". Which is why some of these codec implementations can differ wildly in quality and performance. And this setup is why the same file can (usually) be played by different implementations /brands. Some codecs are unique to their chosen spec format, but mpeg- and itu-authored specs have had many brand implementations.

In general, when most people talk about codecs, they are referring to the overarching format specification that those codecs are striving to be compliant with. Sometimes, especially when comparing quality or efficiency or speed of operations, what is really being discussed is the specific implementation. The "brand" of tissue, even when it might be casually ALL called "Kleenex".

Note, the codec is not the media stream itself, either.


Scott

[videobruger]

Sorry.

I still can't grasp your folder/file relationship and the link I provided may not be relevant.

You have a lot of folders (are they subfolders to a common folder?) each having an image like CatNr.png and some wav files named like 01-Artist - Title.wav and you want to make a video for each wav file in the folder using the same png file and named after the wav file.

Is that correctly understood?

[TB-303]

Is that correctly understood?

yes!

the path looks like this:

D:\ABC\ABC001\Artist - Title\

this goes up to ABC068\Artist - Title\

every of those 68 folders includes the cover as e.g. ABC001.png and several WAV files (usually 8-10).
overall I have 655 WAV files which need to be converted to video, incl. the corresponding cover as still picture.

[TB-303]

thnx for the explanation Scott!