Forum

Results 1 to 13 of 13
  1. #1
    Join Date
    October 2018
    Location
    France
    Posts
    19

    Multitrack record feature

    Hi Team !

    I'm using the Multitrack record feature to record my RPG session. After importing audio to Adobe Suite (Audition, then Premiere Pro), I observed that all wav tracks does not have the same duration. Which is a bit a pain because then you have to synchronize each track to another.

    Could you fix it so every track recorded has the same duration ?

    PS : During those sessions, everyone (track) was connected from start to end. So, not an issue with someone joined after record started.

    Also, for each client recorded the File name contains the nickname which is good. But the recorder does not. Could you fix it also ?

    Best Regards,
    Lix

  2. #2
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    The difference in duration is a result of different end cuts, i.e. I don’t write unnecessary silence at the end of tracks.
    The start points however should be all on the same Timestamp.
    If you have to move the tracks to different time positions to have them in sync, you have found a bug we hadn‘t seen in internal testing.

  3. #3
    Join Date
    July 2019
    Location
    London
    Posts
    1

    Thanks.

    Thanks for information! I have same problem before.

  4. #4
    Join Date
    October 2018
    Location
    France
    Posts
    19
    I confirm. I have to manualy sync the tracks in Premiere Pro.
    It's like if each tracks starts recording in the same CPU thread one after another.

    The miss-synchronization of 0.10 to 0.41 seconds.
    At 0.10, it's almost not observable (just feels strange, but most people don't find why), but at 0.41, it is very disturbing.


    However, I think you should considere writing empty ends so it's more intuitive for content creators to work with.
    And btw, probably more easy to find the bug because like this, all tracks should have the same duration.

  5. #5
    Join Date
    August 2015
    Posts
    55
    As from my work as audio technician I know both sides and just give some information to the team to consider:

    Sure, you don't like to have empty files or just silence at the end or the beginning. Also you might should disable tracks which are not used in one recording session as it would just be a waste of storage.
    BUT: As first there is a job called "cutter" (yeah I know there is also one for synchronizing but this should normally not be used for that low side recording and has other and more psychological resons behind it). If my recorders would just always delete silence on their own I or somebody cutting things would have much more to do. Alright, timestamps could work but not as soon as video recording with different recorders pops in (in normal circumstances).
    I could surely think about an option in my recorders to just make a new file if there is silence. That would just need some RAM and some code working as like an audio-gate does just recoded for producing a new file.
    The problem is: As people working with the audio or also video you want the raw files. How often did I get shitty encoded or cutted stuff and had to go hours to finally get raw material from the customer and do all the shit on my own in minuts what others tried in days. Since most events today just need to be fast and nobody is going to prepare things properly anymore, you can find lots of stuff which has sort of those problems.
    People working live with audio and video just want raw files with everything in it! We are there to know it, we are there to work with it and there is much less to do at the end, since you use gates, compressors and some other stuff anyways.

    Cheers guys

  6. #6
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    Well, to put things into perspective a bit, no audio person needs to hold back here, if you throw a request at us like "I'd like some Mixer view with four insert vst plugin slots and a Neve-style EQ per TS channel", that's understood (and if it ain't there's always the google and the inquire). I'll leave it up to speculation if I could knock such out by tomorrow , but it'd be understood.
    So, while I would claim to know my bit about audio, I definitely don't know all, especially when it comes to the area of broadcasting or video.

    Hence, let's draft the how and why it came to the silence cutting the way it is.

    (Cutting silence on start)
    In the feedback thread of the client beta, there was the request to not put silence at the start and use the timestamp filename convention instead.
    Argument pro: If someone only says sth. after 45mins, there's otherwise a lot of wasted space.
    I had thought about that, but decided against it, because while the former situation can arise, no denying that, cutting silence in the beginning every single person using the feature would have to always manually synchronize every single track. That's cumbersome. I also didn't find it very attractive to add some sort of silence-period threshold that'd switch behaviour. I found the benefit wouldn't justify the cost for anything else than putting all tracks on a common start point - especially given that there's such a thing as a time frame given for implementing "Multitrack 1.0", I'd rather aim for a robust core functionality than enthusiastically adding things on top already.

    (Cutting silence in the middle of things)
    Also, following that, the next logical step would be "what if someone says sth., then doesn't for 45mins, then says sth.". Going down that road would've only made sense for me using some other format capable of putting those clips in a container, OMF, AAF? Support for those kinds of formats was both a bit out of scope for the time we wanted to invest in this feature for now, as well as there's the problem that support for those kind of formats isn't as wide spread amongst audio editors as I would've liked. Technically wav even has that, however that is again rarely supported. Hence "Stem export", leaving silence in.

    (Cutting silence at the end)
    For silence at the end, and we're not talking -80dB, -200dB, we're talking pure, digital zeros silence here, where there's no breath to be accidentally cut due to a gate threshold setting or anything like that, I simply didn't and admittedly still don't see any negative impact on doing that. However I'm happy to learn if there is. You'll just have to talk extra slow

    ---------------------------------------------
    @lightpsycho
    I'm not entirely sure if you disagree with the reasoning above or sth. else specifically, or just wanted to share some insights from someone in the audio engineering biz?

    QA couldn't reproduce that offset that leads to Lix [PLS] having to manually synchronize the tracks.
    I suspect network jitter [correction] could be the hidden cause here instead of some general miscounting of samples in the recorder itself. We'll keep on trying to spot misbehaviour.

  7. #7
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,799
    I know the first part about cutting silence at start was likely my suggestion, unless there where others that also suggested.

    I would still like like an option though if there is any more updates to this area of TS3. Example of why I dislike leading empty on files for users that join later in a session: If a user leaves the channel 5 times and returns every time that is 6 files for that one user, assuming they were there at the start of the recording. But if they do that 45 minutes into a session you end up with about nearly 4 hours (0:45 * 5 = 3:45) of tape if on each join a file is created with silence back to the start time of the recording.

  8. #8
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    Quote Originally Posted by Screech View Post
    Example of why I dislike leading empty on files for users that join later in a session: If a user leaves the channel 5 times and returns every time that is 6 files for that one user, assuming they were there at the start of the recording.
    Is that an observation on the stable release?
    If a user leaves and rejoins a channel 5 times, his track should resume 5 times.

  9. #9
    Join Date
    August 2015
    Posts
    55
    @thorwe
    I just wanted to give everybody that side of view from audio engineering, trying to write it simple.

    I mean, I really understand the two side, there could also be a third side tbh but I don't want to go too deep inside it.
    I will try the multi recording feature somewhere next week and give you some more input from my side of view, once as gamer and home-pc-worker and the other side as professional pc worker/audio engineer. Maybe we have a good base where we could discuss about that stuff. Just give me some more days.
    I will also get a try on the addressed things.

    @thorwe I think you missunderstood Screech. It was more an example what could be a problem when leaving the silence in a file at the start. But then I don't understand why he comes to 6 files. Just leave the one file recording ahead for the session - but that comes to a far bigger problem at one point: What if you record for 2 hours and have 50 differnt people joining and leaving. Some maybe disconnect, alright, file is probably getting ended - (what if the guy drops? Then a new file would again be created or you just leave all tracks running until you press stop)
    Anyways: 50 tracks are 50 tracks and you would just get a mess and CPU load would probably unsynchronize at one point at the timestamps, since I assume video also recorded and heavy load wwill be produced from a game.

    Well, I will go in my mind thinking about all the addressed stuff and give my oppinion after testing the recording feature (what I sadly didn't do until today - too less time on the PC since the release)

    Cheers and have a nice sunday guys, I gotta work hard again haha

  10. #10
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,799
    Quote Originally Posted by thorwe View Post
    Is that an observation on the stable release?
    If a user leaves and rejoins a channel 5 times, his track should resume 5 times.
    OK, I'll retest. Don't recall feedback on what was going to change from the pre-release feedback, just a thanks for it. So I didn't know what was changed to retest.

    Update: OK, just switching channels the client resumes on the file, but as mentioned by lightpsycho, if they disconnect and reconnect the client ID changes and a new file is created.
    Last edited by Screech; August 5th, 2019 at 12:37 PM.

  11. #11
    Join Date
    May 2016
    Location
    Idar-Oberstein
    Posts
    163
    Quote Originally Posted by lightpsycho View Post
    Anyways: 50 tracks are 50 tracks and you would just get a mess and CPU load would probably unsynchronize at one point at the timestamps, since I assume video also recorded and heavy load wwill be produced from a game.
    That's not quite how I did it, although I haven't done much stress testing myself I'm nonetheless rather positive it performs better than say, DAW recording.

    Maybe that's an interesting tidbit to outline, as the usual assumptions of digital recording don't translate one to one to the way I implemented that.
    Being a DAW user, that was naturally the picture in my mind the initial moment I got tasked with this (Nuendo 3.x mixer + track view for whatever reason).
    However, then the realizations come in, that there're some interesting differences in context.

    First and foremost, for an initial release I didn't want my hidden agenda to transform TS into a modular DAW with voice com to be exposed , hence I didn't want to add a mixer view with manual track arm. Things should be simple.
    There's our first difference, tracks are manually armed and sort of more deterministic in DAWs. You may arm another track, but your interface won't spawn new I/O's, so to speak.

    Then, and that's why the recording code ended up having some twists, there's the...let's call it concurrency of information and the system context in which recording is used.
    For the later, DAWs may rightfully assume to run on a dedicated machine, whereas we're still in the domain where we want to disturb the gaming experience the least possible.
    For the former, looking at it from a musical perspective at least, there's loads of activity simultaneously on each track. The drummer ain't stop playing cause the bass player's going to hit a note.
    Whereas with voice communication, if a dozend people talk at once, figuratively all hope is lost.
    Hence, a DAW doesn't really have an incentive to leave the road of the KISS (keep it simple stupid) principle of just pushing those buffers, whatever may be in it, to disk. This...concurrency of information summing up to the musical piece is the natural state of affairs.
    So, simplifying a bit, but in principle I'm instead applying a "write the least, only once necessary while still avoiding large, long blocking I/O bursts" idiome.
    The "cut" of silence from the end of file we discussed earlier, therefor technically came extremely cheap code wise due to that specific way of implementation. There's nothing to remove, so to speak, it just doesn't explicitely get added before closing the file.
    Similarly, you'll notice that the file size of a player track doesn't increase while the user isn't talking.

    There's a nice benefit falling out of that in a TeamSpeak context.
    If you got 50 people, and one is talking, only one file is being written at that time (+ maybe something queued up to be written out).
    Those other zeros may need to be written at some point, avoiding too much of a spike in disk activity to not block gaming or anything else that may want to interact with the disk, but they don't need all to be written at once when there's no information in 49 of them.
    Hence, the linear increase in performance requirement like with track arming in DAW's can be circumvented and larger 'overall track counts' supported, given the assumption 50 people talking at once is gonna be a temporary rare event.


    Quote Originally Posted by Screech View Post
    if they disconnect and reconnect the client ID changes and a new file is created.
    There's a ticket on ToDo for resuming on disconnect too indeed.
    Didn't make it in as it's a bit of a pain doing it properly, with the potential of multiple clients using the same identity asf. I preferred having more files in that case for the moment over adding it quick'n'dirty and fail horribly for n edge cases.
    Last edited by thorwe; August 5th, 2019 at 07:29 PM.

  12. #12
    Join Date
    August 2015
    Posts
    55
    Quote Originally Posted by thorwe View Post
    There's a ticket on ToDo for resuming on disconnect too indeed.
    Didn't make it in as it's a bit of a pain doing it properly, with the potential of multiple clients using the same identity asf. I preferred having more files in that case for the moment over adding it quick'n'dirty and fail horribly for n edge cases.
    Yeah that's fully alright! Quality over quantity is the real target to hit. Therefore I just really can wait for it. Also while thinking about the problems happening with the reconnection and multiply identity usage I would just give up as a casual coder for that moment haha.

  13. #13
    Join Date
    October 2018
    Location
    France
    Posts
    19
    Hi Team !

    thanks thorwe for the checks.
    Next record will be by Septembre or october.

    Maybe you can set a parameter (checkbox or something like that) to enable / disabled the silence at the end of tracks to be written ?
    At least, it could help us to compare files more easily...

    Best regards,
    Lix

    PS : sorry for long time with no talk... summer holidays ^^
    P.PS : btw, this feature will be conserved on TS5 (i would be a mess if not) ?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. [On Todo] Doesn't work Start Multitrack Recording
    By PavelKotov in forum Bug Reports [EN/DE]
    Replies: 4
    Last Post: October 14th, 2019, 08:27 AM
  2. SRV record help
    By Col_Crunch in forum General Questions
    Replies: 15
    Last Post: December 21st, 2013, 03:49 AM
  3. Replies: 0
    Last Post: June 19th, 2013, 05:56 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •