IDEA: edit decision list preparation for long audio files, subtle GUI...

[mutetourettes]

Hello all - I have an idea for a small programme, hopefully quick for the ninjas here....

It's kind-of an audio player, but with an additional layer of annotating/organising/editing what's being played

use case: - long source audio files (e.g. 3 hours) with multiple songs or parts of discussion/book etc etc
I want to prepare an edl (Edit Decision List) at work, listen/mark/name/reorder/join etc which creates a txt-based edl  file saved alongside (same name as) source audio file, then finally when I'm satisfied with the edl and how it plays, dump out edited waves with filenames as defined in the edl.

ideally run as portable executable without install (or at least the option to do that), run on any operating system from vista to current.. (I'm mostly in win7_64 but likely to change soon at work)

Interface must be small, minimal, (no big wave display etc). I.e. it's unobtrusive on a pc in an office at work, so these long audio files can be worked steadily through on headphones without much taking eyes off doing whatever boring office job, and without making the boss think you're doing anything much else.

Just non-garish display of time position (click for time remaining this track, time remaining whole file), track number+name, and then some transport (play/pause/prev/rew/fwd/next/repeat) and mark/split/join/up/down/ignore buttons, info button and file open/save/save.
click on the track name to type in a name.
click 'mark' to mark a point in a track. uh.. some method to unmark as well?
'split' to split a track at the most recent mark. actually, thinking about it, maybe split and mark can be one and the same...
'join' to heal/join a track to whatever precedes.
'move up' to move a track up the order.
'move down' to move a track down.
'ignore' moves a track to the end of the edl and calls it e.g. ignore01, ie a file won't be created for that track when they're all output - renaming it will bring it back into the output list (and put it back before all the ignores).

This kind of simplicity is found on e.g. old portable minidisc recorders. there is no visualised element, just listening and not-too-heavy thinking, but full capability to make a complex non-linear TOC (Table of contents i.e. an edit decision list on a minidisc) from whatever originally got recorded. e.g. http://minidisc.org/...50_manual/index.html

cuts/joins must not involve encode/reencode, fadeout, crossfade or anything else - it's pristine/bitperfect and could be rebuilt with no loss.

Perhaps ideally cut/join at zero crossings

must have mono/stereo capability of 8 to 32 bit samples, and any sample rate supported - ie very basic system sounds to very very high quality audiophile/studio sound. I'm looking at pcm wav files initially, don't really care about other formats (e.g. i believe there are issues about trying to spilt mp3s at arbitrary positions without alteration - it's unnecessary extra complication for v1.0).

In a concession to actually being on a computer with a nice big screen an info button might open up a bigger overview screen showing the full edit decision list, track names (renamable?) etc, maybe click to play. maybe the edit times might be editable.. if there's been a lot of joining/moving then this screen will be interesting, could be several lines of edits for one 'track'. also this screen could be useful for getting out of a jam, or doing some 'undo'... i'm not sure about this..

'open file' chooses the source audio file to make an edl for: opens file and immediately creates an edl file for it.
'save edl' saves the current progress of building the edl file - closing the programme will bring up this as a question.
'output files' makes new wavs according to the edl. [dialogue box to ask for where to save to, and also if there should be a common prefix. add track no etc..]

clicking 'repeat' cycles between 1,all,none,(shuffle? - plays all non-ignored sections)
clicking 'rew'/'fwd' cycle between several speeds of audio scrubbing with the intention that you can quite accurately place a mark point by ear, but also fairly swiftly wizz through ten minutes of dross..

Possibly, in a further concession to being on a computer with a mouse, a very small (but I suppose fairly wide) clickable position indicator line representing the whole file, to allow for very rough navigation, so you'd not need to hold 'fwd' down for ages to get two hours into a three hour file...

v2.0, ie things that might be sweet for some folk but i don't care about and will probably just add complication:
- recording capability,
- other formats of audio file,
- edit the times in the edl overview window
- save wavs can save in other formats too (more palaver, metadata etc?)
- crossfade joins (and associated palaver, curve shape, onoff etc)
- bring multiple source files into one edl (more associated palaver, where does the edl get saved? different formats?)
- output xml based edl - maybe compatible with some video e.g. FCP  ones?

[mutetourettes]

...tumbleweed.....   

I guess this didn't look very snackish to anyone, maybe it's the closeness of NANY... maybe my eyes were bigger than my stomach!

So I'll try and break it dow into suggested snacklets in order of desire... maybe a little more snackish.. any of these look too chewy?



Basic Player:

1) a simple audio player - maybe you already have some code for this - can it handle large/long/high resolution files? ideally small, portable

2) a simple gui. a very simple gui, play,pause,back buttons , display time readout.

3) add fwd/rew winding/(audio scrubbing?) buttons for navigation - the desire here is to be able to position a point very accurately, so slow scrub - but also they're big files, so fast wind available too.



Track Marking:

4) add ability/button to drop trackmarkers at desired timepoints, held in an array of 'tracks' that each have a start and endpoint- this change implies gui display will now show what 'track' we're now playing, back button now goes to last marker (and can go to previous track too if repeated presses fairly close together), new 'next' button. default condition is that track 1 begins at the beginning and ends at the end of the file

5) add ability to snap these markers to zero crossings, (or chunk boundaries for mp3?).

6) a 'join' button that will join the current track (as defined by the position of playback) to whatever is before - at this point this is simply the removal of a track marker (and line/row in the array, and revising the endpoint of another line, and consequent renumbering of later tracks in the array)

7) add ability 'Save EDL': save array as a simple text file using name of original audio file and different extension e.g. .edl the text file format is to be pretty simple, so can be human-edited without too much difficulty. I suggest the track numbers are not written in the file - use lines/rows instead. Although the idea is that the file is only manipulated by the program, at least initially, otherwise there's lots of odd cases to handle, eventually it will handle a bit of manual editing, and this means a human can remove a line without doing a full renumber.

8 ) now when an audio file is opened in this program it will look for a matching .edl file and load it into the array. At this point not huge checking for validity of file.



Audio dump:

9) a new ability 'Save Audio Files': to dump all audio out to individual files according to the trackmarkers. original file name with trackmarker suffix added. The cuts must be non-destructive/flawless/bitperfect.



Naming:

10) add ability to name these 'tracks', for the track currently playing (as defined by position) click in the gui display and either dialogue box or directly type the track name, also held in array, also saved in file - track and name are shown in gui display. Now name is used in addition to number suffix when dumping audio out. (some kind of dialogue box/setting about file naming convention?)



Ignore

11) add an 'Ignore' button so that the current track (as defined by playback) is renamed '#Ignore', effectively it's just a shortcut to give the current track the name '#Ignore' The segment stays where it is in the Array/File though. it is then NOT included in the audio dump and regardless of what row/line it is in the list it is only played after all the other tracks. 

12) if a human edits a file, they may leave some time periods of the original audio file unused. I suggest they're recreated by the program as lines in the array/file in the appropriate chronological position named as '#Ignore'.

13) renaming (or blank naming) an '#Ignore' track reinstates it. when this happens it might be worth a dialogue box flagging up what track number it just became



ReOrdering

11) ability for re-ordering: 'up' and 'down' buttons move the current track (as per play position) up or down the running order: here we're telling the program to play a segment of audio out of its original order. also a human can move a line up or down in the .edl file. This implies:

11a) the 'join' button - having moved tracks about a bit the 'join' button may now be asking to join two segments of non-continuous data - if so these two joined segments must still maintain their individual lines in the array/file with start/end positions but there needs to be a standardised flag on the second segment indicating '#joined to previous' (actually that could be in the 'name' part couldn't it, as it inherits the name from the first segment). When reading a file the track numbering would need to skip over these 'joined to previous' lines. In playback the user sees it as one track which plays through the join seamlessly. If one of these multi-segment tracks gets moved up or down, all of its segment lines must move with it!



Undo

15) some levels of undo, so changes can be rolled back....



Large file search

16) add search position/slider/bar/thing for improved navigating very long files



Further elaborations

17) handling bwf files using original meta data and putting it into the dumped audio files

18) play-engine sweeteners like 'repeat/shuffle', any other shenanigans from previous post

[KodeZwerg]

I do somehow understand what you want, but this aint a coding snack, this a real full application with alot of user specific wishes that you are talking about.

Free coders like me scare all your wishes and specifications away.

[mutetourettes]

Hi KodeZwerg

ahhh, ok.. not a snack - perhaps it could be moved to a more suitable part of the forum?

I wrote a lot in the hope to be specific and clear, didn't want to scare anyone away 

[KodeZwerg]

@mutetourettes, the forum you picked is good, how specific you are is good, if someone answer this call.... lets see

[wraith808]

What does audacity not do that you're asking for?

https://www.audacityteam.org

I personally use GoldWave, and I know that it does it, but is paid

https://www.goldwave.com

[skwire]

As KodeZwerg said, this is well beyond a Coding Snack (and a NANY for that matter).  That said, I do appreciate your vision for this app.  Also, your level of detail is great and it, rightly, exposes how complicated this app would be on the programming side of things.  Over the years, mouser and I have had many conversations on how something that sounds very simple is extremely difficult programmatically.  On the flip side, there have been many times where a user has thought their idea very complicated but, programmtically, it's very easy.  Additionally, there are times where the input and output is simple, but the GUI design is very complicated and takes much more time to implement than the actual input/output code.  In my opinion, your idea is complex in both GUI design and input/output design.

Have you looked at any audio or video editors out there that you might be able to strip down the interface a bit in order to get close to what you want?

[wraith808]

The thing about audacity is that since its oss, if it comes anywhere close, it might be easier to customize that, or the modifications might be something that the team on it would consider

[mutetourettes]

What does audacity not do that you're asking for?

https://www.audacityteam.org

I personally use GoldWave, and I know that it does it, but is paid

https://www.goldwave.com

-wraith808 (December 04, 2018, 07:51 AM)

Thanks Wraith,
I've used audacity in the past, I wonder is it possible to run it with a very minimal interface?
I didn't know about goldwave - might have a look at configuring that to minimal

[mutetourettes]

ok, so lets say I fancied writing this - is BASS a good library to use?

I have visual studio (various years) in which I do sql server reporting services, and also some .net and c# website stuff.

I've used vba (visual basic for applications - ie MS access etc) and a while back I did do some customising of someone else's audio project in vb6 I think. (that stuff sadly no longer available to me).

I'm not familiar with writing an actual exe from scratch though. I'm windows-centric in use.

What language/environment would you all recommend?

[KodeZwerg]

Bass is easy and understandable to handle, contain demo for many aspects and not just in one language.
(Delphi is my language, i am okay with it)

[mutetourettes]

realistically, between job and toddler I don't think I'm going to be able to dive into coding this up...

Hey skwire - does Trout already do some of this?

[skwire]

Hey skwire - does Trout already do some of this?

-mutetourettes (December 05, 2018, 03:13 AM)

Trout uses the BASS library and plays back various types of music files.  It doesn't do any of the editing or custom stuff you described.

[Nod5]

Just a small tip: mp3 file id3 tags supports chapters. If some suitable audioplayer supports showing chapters during playback (VLC perhaps? At least it does for video files) then some of the requested features could perhaps be made through a small frontend app that uses VLC and some id3 tag command line tool to create/adjust chapters and to export/cut audio. FFMpeg also seems to have support for id3 chapters in mp3 files.

Another idea: Some audio players support .cue sheets that make one big audio file appears as multiple tracks. A frontend tool could based on user input edit the plaintext .cue sheet and then reload it in the audio player to achieve some of the requested features.

[mutetourettes]

Would I be insane to try and program this using SDL 2.0 ?

I ask as I've found a youtube series to guide me through the baby steps.. I find getting the ball rolling is the hardest part. SDL seems to be mostly for games developers though, so I'm slightly worried it's the wrong tool...