I’m part of a small group of Jr Self Taught Web Developers who were recently brainstorming ideas for a Group Project App we could put together and actually create a user base.

I offered up the suggestion of a podcast application which would have the major feature of being akin to YouTube Sponsor Block, but specifically for podcast episodes.

Essentially, a user contributed database of timestamps for podcast episodes where the mention of cutting to sponsored ads or mentions of sponsorships would be marked so they could be edited out of the episode and then the user could also download said episode where ads are cut out of the final audio file.

My idea was shot down due to fears of possibly infringing on copyright and we ended up with going with another idea. I’m certainly not upset, and am actually excited with the project idea we did choose, but it did get me wondering about whether this idea actually could have legal implications.

I know specifically with YouTube there appears to be a sort of legal loophole that prevents Google from suing projects like invidious, yt-dlp, and YouTube Sponsor Block, but am unaware of the specific details as to how this works.

Thusly, I just wanted to ask if anyone has any insights into whether this project idea would incur any legal infractions from the likes of IheartRadio and other media platforms?

To be clear, I’m not seeking legal advice here, and I’ll be taking any responses with a grain of salt, but I just wanted to see if anyone knows anything on this subject and the legal concerns raised.

I very much dislike being advertised to and podcasts are one of the last bastions of media where advertisements still come up regularly and I’d love to make this application for those who are frustrated with how often they have to skip through sponsor mentions.

Thanks in advance.

  • tubbadu@lemmy.kde.social
    3·
    9 months ago

    Other answer seems to suggest that the problem is that the same podcast can be available, depending on where and who is listening to it, with different length due to different ads injected into. Here’s my probably stupid and completely ignorant suggestion: instead of using timestamps for both begin and end of the ads segment, you could use a timestamp for the beginning, and an hash of the first part of “non-ads” segment. I’ll try to explain better:

    |----------------xxxxx--------------------|
                ^     |___|

    The xxx is the ads segment, the ^ is the timestamp of the beginning of the ads, the |___| is a small duration segment (for example, 0.5 seconds) right after the ads segment. The data of that segment is hashed and used as “end ads segment indicator”.

    On the other device, with a different duration of the ads, you should start hashing it to find the corresponding segment.

    Is this doable or did I just said a bunch of idiot things?

    • z3rOR0ne@lemmy.mlOP
      1·
      9 months ago

      Possibly doable, and definitely not a bunch of idiot things.

      The beginning of the FIRST ad certainly does start at a consistent point during the podcast episode, but due to the dynamic nature of the injected targeted ads afterwards, the remaining timestamps for the beginning of the subsequent ads would be different. The hash of the audio file was suggested by another helpful person earlier, and it has piqued my interest, though it’s implementation, at least as I conceive of it currently, would be rather clunky, as it would require an ad free version of the audio file to compare it against, as well as a way (possibly a hash or some sort of audio recognition software, or AI trained to recognize ads, effectively acting as audio recognition software), to recognize exactly when the ads started and stopped by comparing the ad free version second by second to the ad-injected version.

      Additionally, because re-distribution of said audio files would definitely land me in legal trouble, I’d have to dynamically generate those timestamps and send it to you while you received the audio file from the official distributor, all to be edited on your device upon arrival.

      I’m still very much a noob at programming and webdev, so this is definitely something that is probably a few years down the line in the making as I continue to upskill, but it’s good to think about as I would like to produce this if at all feasible (and won’t land me in legal trouble or hurdles, I’d like this to be akin to Invidious and Sponsorblock if possible).

      Thanks for the suggestion! You definitely got me thinking hard on this problem and its potential solutions.